Onderzoeker ontdekt gevaarlijke bug in Linux-usb-driver

Een beveiligingsonderzoeker heeft een bug gevonden in de Caiaq-usb-driver, die breed wordt toegepast in de Linux-kernel. De bug kan worden misbruikt om na het creëren van een buffer-overflow toegang te krijgen tot een Linux-machine.

Volgens Rafael Dominguez Vega van MRW InfoSecurity gaat het fout als de Caiaq-usb-driver via het strcpy-commando de naam van een aangesloten usb-apparaat wil uitlezen. De strcpy-opdracht controleert niet de lengte van een usb device name, waardoor het gereserveerde geheugengebied van tachtig bytes kan worden doorbroken en een buffer overflow ontstaat.

Door een usb-apparaat te voorzien van een extra lange apparaatnaam is het mogelijk om een buffer-overflow te creëren, waarna code geïnjecteerd en aangezet kan worden. Vega stelt dat hij erin is geslaagd om een usb-apparaat in elkaar te zetten waarmee het mogelijk is om toegang te krijgen tot een Linux-systeem, een aanvalsmethode die hij op Twitter kwalificeert als 'Linux plug&pwn'.

Het onveilige strcpy-commando werd pas in februari vervangen door het veiligere strlcpy-commando in de Linux-kernel. Strlcpy controleert de lengte van een string, in dit geval het apparaatbeschrijvingsveld van een usb-device. Desondanks zouden er nog talloze kwetsbare Linux-kernels in omloop zijn, mede doordat vrijwel alle distro's gebruikmaken van de Caiaq-usb-driver. Hierdoor bestaat het risico op aanvallen, al is fysieke toegang tot een usb-poort van een server of pc noodzakelijk.

De usb-aanvalsmethode is niet geheel nieuw voor het Linux-besturingssysteem; in februari demonstreerde een onderzoeker een hack waarbij via een usb-stick toegang werd verkregen tot gebruikersdata in een Ubuntu-systeem.

Reacties (164)

[clueless12]

Net even een 'grep -r "strcpy(" *' op de hele linux source gedaan en het wemelt er nog van. Ook nog op een aantal plekken waar de source niet gegarandeerd kort is. Wel is het zo dat het daar meestal om namen van hardware in de computer gaat. Is toch wat lastiger een buffer overflow voor te maken dan een USB device.

De linux kernel wordt niet alleen op PC's gedraaid maar ook op router en telefoons (Android). Ik weet niet of die dermate aangepast zijn dat dit niet geldt maar dit kan natuurlijk erg handig zijn om een 'geleende' telefoon even van wat 'monitoring' programma's te voorzien. Of bij een router om toegang te krijgen tot opties die normaal achter een wachtwoord zitten.

[Dreamvoid]

Hoe denk je dat mensen die Android telefoons kunnen rooten? Juist ja: overflow exploits. Idem met iOS jailbreaks, WP7, etc.

[clueless12]

Waarschijnlijk wel ja maar dan moest je altijd nog wel toegangsrechten hebben. Nu misschien door het insteken van een USB device waardoor je even snel iemands telefoon kunt 'tweaken' zonder daadwerkelijk in te kunnen loggen op de telefoon.

[johnkeates]

Dat zegt niets. Je moet eerst diezelfde usb driver hebben, plus een USB poort. Daar naast is een strcpy niet automatisch onveilig, je kan buffer overflows op meerdere manieren afvangen.

[postbus51]

En jawel je moet wel een Caiaq device hebben , dus een sound-usb apparaat
Geen gewoon usb stickie

include support for caiaq USB audio interfaces, namely:

* Native Instruments RigKontrol2 * Native Instruments RigKontrol3 * Native Instruments Kore Controller * Native Instruments Kore Controller 2 * Native Instruments Audio Kontrol 1 * Native Instruments Audio 8 DJ

Hier snipper van patch

@@ -136,7 +136,7 @@ int snd_usb_caiaq_midi_init(struct snd_u
if (ret < 0)
return ret;

- strcpy(rmidi->name, device->product_name);
+ strlcpy(rmidi->name, device->product_name, sizeof(rmidi->name));

rmidi->info_flags = SNDRV_RAWMIDI_INFO_DUPLEX;
rmidi->private_data = device;

[Reactie gewijzigd door postbus51 op 24 juli 2024 07:14]

[_JGC_]

Nee, je hoeft helemaal geen Caiaq device te hebben, je hoeft alleen maar een apparaat te hebben dat zich voordoet als een Caiaq-device. Linux komt met een kerneldriver die het mogelijk maakt om je computer voor te doen als USB apparaat. Met die mogelijkheid zijn er mensen aan de slag gegaan om met een Android of Meego telefoon een Playstation jailbreak tool te bouwen, gewoon je telefoon aansluiten op je Playstation en je hebt dat ding gehackt.
Nou bouw je gewoon een app die je telefoon zich voor laat doen als een Caiaq-device, je maakt zelf een device string die te lang is en je sluit vervolgens dat ding aan op een willekeurige linux pc of server met USB en een oude kernel. Afhankelijk van wat je uitspookt resulteert dat in toegang tot kernelspace, een gecrashte kernel of datacorruptie. Ondanks dat je telefoon geen Caiaq-device is, zal linux gewoon die driver laden en proberen je telefoon te herkennen als zijnde zo'n device.

[postbus51]

Niet echt a: Ik heb die driver niet gecompileerd dus laden onmogenlijk via alsa
en is dus al gefixed voornu
b: Je moet Fysieke toegang tot mijn usb poorten hebben en das moeilijk
ik weg aka AFK alles locked en ook geen mogenlijkheid tot hotplugging
dus nada usb firewire esata geen (weet niet met mindcontrolling de cpu&mem )

[Reactie gewijzigd door postbus51 op 24 juli 2024 07:14]

[johnkeates]

Valt allemaal wel mee.. fysieke toegang vereist, plus het is een exploit die nu gereleased is voor een fout die een maand geleden gefixt werd. Alle grote distro's zullen al gepacht zijn... Alle niet gepatchte systemen zijn waarschijnlijk of niet in gevaar, of gewoon niet kritiek.

Op de site van deze 'onderzoeker' staat "Mar 07, 2011", wat betekent dat deze 'onderzoeker' ook gewoon heel goed even in de git repository had kunnen zoeken naar security patches. Als ik die patches langs ga, en een opgelost probleem vind, kan ik dus ook komen mekkeren dat ik een fout 'gevonden' heb.

[Reactie gewijzigd door johnkeates op 24 juli 2024 07:14]

[Cyberslak]

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Nu is dit weer een probleem waarbij je direct toegang moet kunnen krijgen tot de machine.
Wat bij bijv. een server normaal gesproken niet zomaar kan.

[Oeroeg]

De vraag is of je dit als een lek kunt beschouwen.
Je moet immer fysieke toegang tot de machine hebben, en als je dat al hebt, dan is het meestal ook niet zo moeilijk om in een recovery modus als root op te starten.

[humbug]

Kom kom, lek is lek. Zoals de onderzoeker al zegt "Linux plug&pwn" Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk. Dat er ook andere manieren zijn, tsja. Dat is bij de discussies over veiligheidsgaten in Windows ook nooit een probleem

Linux heeft net zoals OS/X of Windows gewoon een hoop veiigheidsgaten. Soms is het pure onkunde maar veel vaker is het een gevalletje pech hebben. Je kan nu eenmaal niet alles dichttimmeren. Wel is het nu zaak om de driver snel te vervangen zodat ook dit lek weer snel gedicht is.

[kidde]

Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk.

Leuk leuk hoor, maar hoeveel servers hebben ondersteuning voor USB-sound? Als het goed is praktisch geen één, want ik ga ervan uit dat een beetje server-admin de kernel aanpast voor de bak waar dat ding op draait.

Ik wel voor m'n desktoppie, en nee, die heeft geen USB-sound ondersteuning.

Dus nee, je kan niet alles dichttimmeren, maar in Linux kan je wel eenvoudig de troep weglaten die je niet nodig hebt. Eenvoudiger dan in sommige andere kernels, lijkt me.

Natuurlijk is er in Linux een nogal groot beveiligingsprobleem omdat er geen 'capability based security' is (zoals A. Tanenbaum altijd graag uitlegt), dat dan weer wel. Want had dat in Linux gezeten, dan was het risico / gevolg van het uitbuiten van dit lek veel beperkter geweest. Maar ja, dat is al jaren bekend, en helaas zijn er weinig kernels die dit probleem verhelpen.

[Emmef]

Het leuke is dat het capability systeem wel is (zie SELinux), maar slechts wordt gebruikt voor een klein aantal zaken (zoals realtime scheduling permissies) en dan nog via PAM modules. Je kunt het ook hard in je filesysteem opnemen en per proces de capabilities instellen (inclusief wat er te erven is naar sub-processesn) maar de meeste programma-makers en distros hebben hier geen zin in.
Zo kan een web server die draait onder een andere user dan root best onder poort 1024 draaien (wat normaal alleen root mag) door een attribuut op te nemen voor de executable. Maar als je dan ook oudere bestandssystemen wilt ondersteunen werkt dat niet, want die ondersteunen de extra attributen niet. Tja: en dan moet je weer twee scenario's gaan bijhouden.

[Reactie gewijzigd door Emmef op 24 juli 2024 07:14]

[bzerk]

Klok en klepel?
Je kunt inderdaad dmv SELinux een executable of een user het recht geven privileged ports beneden 1024 te openen. Dit heeft echter helemaal niets met het gebruikte bestandssysteem te maken.
Jij bent in de war met Extended Attributes.

[LollieStick]

Het lek is al gedicht (zie artikel)

[MicGlou]

Het lek is al gedicht in de kernel, maar of deze kernel al breed is uitgerold in de verschillende builds die daarvan bestaan? Dat is wat het artikel ook vermeld en dat is dus verre van... de meeste builds draaien namelijk nog de oude verkeerde driver.

Desondanks zouden er nog talloze kwetsbare Linux-kernels in omloop zijn, mede doordat vrijwel alle distro's gebruikmaken van de Caiaq-usb-driver.

[LollieStick]

Wel is het nu zaak om de driver snel te vervangen zodat ook dit lek weer snel gedicht is.

Dat was het puntje waarop ik reageerde. De kernel-maintainers hebben hun werk gedaan, nu is het de taak van de distro-bouwers of de HTK-kernelbakkers om hun kernel te updaten.

[thechronic]

Iedere distro die zijn naam waardig is backport veiligheidsfixes naar de huidig ondersteunde platformen, en niet enkel voor de kernel, maar voor alle software in de repositories.

[BeosBeing]

Alleen zou het zinnig zijn geweest om te vermelden vanaf welke kernel het gedicht is. Er staat geen versienummer vermeld.

[Verwijderd]

Kom kom, lek is lek. Zoals de onderzoeker al zegt "Linux plug&pwn" Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk

Lek is inderdaad lek.
Maar een datacenter kom je ook niet zomaar in he...
De centra die ik heb bezocht waren in ieder geval allemaal beveiligd met toegangspoortjes, camera's, etc.

[Sorcerer8472]

Bovendien zitten de meeste racks dicht met sloten in gedeelde suites, en is er camerabeveiliging... dus als je al legaal binnenkomt kun je niet zomaar bij alle apparatuur.

Overigens zijn er andere OS'en waar je sowieso al makkelijk via USB virussen e.d. kunt verspreiden (iets met autorun, verder zeg ik niets )

[iMars]

@humbug && lenny_z: Tenzij USB uitstaat op de server. Ik gebruik geen USB op mijn server, en staat in de bios uit

[thegve]

Gebruik je dan ps/2 toetsenborden? Nieuwere servers hebben geeneens ps/2 poorten meer.

[Verwijderd]

raar dat 99% van jouw nieuwere servers toch een ps2 gat achterin hebben... of kijk je daar nooit?

[FreshMaker]

Mijn server geeft in het bios een optie, selctief in / uitschakelen
en type om in te pluggen

als ik kb/mouse heb, werkt een ander apparaat er niet op, zelfs een IR infrarood receiver doet het niet ..

[thegve]

http://www.dell.com/us/business/p/poweredge-t610/pd

Zoekt en gij zult niet vinden!

En zijn platgestampte broertje mocht je het over rack-servers hebben:
http://www.dell.com/us/business/p/poweredge-r610/pd

Heeft hem ook niet.

Wij hebben ongeveer 50-75 R610's bij klanten uit staan, en nog meer oudere types die hem ook al niet meer hebben.

Volgens mij (maar dat weet ik niet zeker), had zelfs de 1900 al geen ps/2 meer, en dat is er een van jaren oud:
http://reviews.cnet.com/s...1707-3125_7-32490746.html

Maar daar kan ik me heel goed in vergissen, niet zo vaak meer in mijn handen gehad (en de hardware hoek is verder ook niet mijn natuurlijke habitat)

edit:
HP heeft nog wel een PS/2 poort zie ik:
http://h18004.www1.hp.com...cs/13241_na/13241_na.html

[Reactie gewijzigd door thegve op 24 juli 2024 07:14]

[Carharttguy]

Gebruik je dan ps/2 toetsenborden? Nieuwere servers hebben geeneens ps/2 poorten meer.

wat dacht je van remote control, SSH bijvoorbeeld?
Ik zie mezelf nog geen toetsenbord/printer/alle-andere-apparaten-op-usb aansluiten op m'n server.

[MadEgg]

Als ik voor maintenance in het datecentrum kom, bijvoorbeeld om een reepje geheugen te vervangen, dan sluit ik doorgaans wel een monitor en toetsenbord erop aan ja; wel fijn als ik direct kan controleren of alles goed gegaan is.

[thegve]

Wat dacht je van installatie, upgrade van server, etc. Is niet allemaal practisch via SSH. Als hij eenmaal op zijn plek staat zijn werk te doen dan uiteraard via SSH (alleen al omdat er dan ook 100+ kilometer tussen mij en de server zit).

[Neverwinterx]

Je hoeft geen fysieke toegang te hebben, enkel een USB device met een lange devicenaam hoef je te verspreiden. Wat natuurlijk niet zo makkelijk is. Als je de naam van bestaande devices kan veranderen, dan zou het pas echt gevaarlijk worden.

[Reactie gewijzigd door Neverwinterx op 24 juli 2024 07:14]

[MRammeloo]

Ach, een 'relatiegeschenkje' op de juiste plek uitdelen...

[johnkeates]

Dus jij steekt alles wat je binnenkrijgt in productie platformen? Dat heeft nog steeds een human error of een PEBCAK.

[brabbelaar]

tja, als ik op een beurs of congres een usb-sticky krijg dan zou ik die wel in m'n laptop duwen om te kijken wat het is ja. Ik heb een virusscanner, ik draai linux... draaide ik windows dan deed ik dat ook.

Er zijn wel eens virussen op nieuw verkochte harde schijven aangetroffen, wat wil je dan? Nooit nieuwe hardware gebruiken?

[Verwijderd]

Paranoid much?

[mae-t.net]

Realistisch. Zo'n ding onbeschermd ergens in steken is nog nooit een goed plan geweest, en dat mag langzaamaan toch wel een beetje publiekelijk bekend zijn.

Onder windows was het al tijden een slecht plan vanwege het "bericht bij automatisch invoegen", dat onder XP inmiddels naar verluid uitgezet is middels een patch, en wegens mogelijke bufferoverflows en onder linux dus vooral vanwege dat laatste. En als dat dan geen probleem is kan er natuurlijk altijd een trojan op staan.

[Reactie gewijzigd door mae-t.net op 24 juli 2024 07:14]

[Jeroen]

Voor mensen die hun computers wel goed beveiligen is dit wel degelijk een lek.

[arjankoole]

Voor mensen die hun computers wel goed beveiligen is dit wel degelijk een lek.

Nee, want die mensen hebben hun USB poorten uitgezet, en draaien bovendien een al lang en breed gepatchte kernel.

[_JGC_]

Mwah, fix is net een dag uit. Ik heb gisteren nog nieuwe kernels uitgerold op een aantal testservers, en daar zat deze fix niet in. Releasedatum van die nieuwe kernels was afgelopen zaterdag (2.6.32.31, vannacht .32 gereleased dus).
Maargoed, in mijn servers mag je gerust een USB stick steken die zich voordoet als een geluidskaart, de kernels die ik draai weten niet eens wat USB is, laat staan dat ze drivers voor een vage geluidskaart voeren.

edit:
fixes die vandaag uit zijn gekomen fixen een soortgelijke bug in een andere driver, maar daarbij wordt vermeld dat het zeer onwaarschijnlijk is dat het te gebruiken is.

[Reactie gewijzigd door _JGC_ op 24 juli 2024 07:14]

[bbc]

Ik krijg bijna dagelijks mails binnen over security lekken via de debian security mailing list. Dat maakt een distro niet meer of minder betrouwbaar. Het toont enkel aan dat er aan oplossingen gewerkt wordt.
Dit is gewoon slechte code, waarvoor nu een fix gemaakt wordt. Op servers loop je niet al teveel risico. Als een onbevoegde fysiek toegang heeft tot je toestellen, is zo een usb stick in mijn ogen niet je eerste zorg.
Het is goed dat de aandacht op deze bug wordt gevestigd, maar dat is het dan ook.

[Verwijderd]

Dit is gewoon slechte code, waarvoor nu een fix gemaakt wordt. Op servers loop je niet al teveel risico. Als een onbevoegde fysiek toegang heeft tot je toestellen, is zo een usb stick in mijn ogen niet je eerste zorg.

Dit hoeft helemaal geen slechte code te zijn, er is iets over het hoofd gezien.

Er is bij geen enkel systeem geen probleem meer als je maar de patches installeert en een gesupporte Linux distro versie gebruikt.

Zie de fix.

De fix is van 16 Februari.
Tweakers/labs.mwrinfosecurity.com als je al nieuws hebt kom dan met iets wat meer up to date is.

Wat me iedere keer opvalt is dat Linux bugs meestal al gefixed zijn wanneer het nieuws naar buiten komt, in tegen stelling to veel commerciële OSen.

Zoals de eerder vermelde Linux bug (staat ook in de post): nieuws: Aanval met usb-disk kan ook onder Linux

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:14]

[Verwijderd]

Ik weet niet of die code nou zo enorm slecht is. Een soort-gelijke bug had de PS3 ook, waardoor via USB ook 'n exploit openbaar werd.

Dit soort bugs zullen bij ieder systeem voorkomen, alleen moet maar net 'n slimmerik 't proberen uit te buiten.

[_JGC_]

Mja, die mails die je van Debian binnenkrijgt zijn ook nogal gevarieerd, vaak gebruik je de software niet eens of staat het gewoon helemaal niet op het systeem. Wat ik minder leuk vind is dat er sporadisch kernel updates zijn, en als ze er zijn, fixen die dingen meteen 10-20 openstaande CVE's. IMHO wil je zo snel mogelijk na de bekendmaking van zo'n bug een gefixt pakket uitbrengen ipv dat je zoiets opspaart tot je er 20 hebt.

[Patriot]

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Nu is dit weer een probleem waarbij je direct toegang moet kunnen krijgen tot de machine.
Wat bij bijv. een server normaal gesproken niet zomaar kan.

Wat vind je daar precies aardig aan? Ik denk namelijk dat je vermoed dat dit aangeeft dat Linux minder betrouwbaar is dan zoals het bekend staat, dat is echter niet het geval. Juist door dit soort mensen komen deze bugs aan het licht en worden ze verholpen, zo kan er geen misbruik (meer) van gemaakt worden.

[magicsam]

Ook best aardig dat de bug al gefixed is ten tijde van dit nieuwsbericht!

[Verwijderd]

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Niemand heeft ooit gezegd dat Linux bug/lek vrij is, maar vergeleken met de concurrentie kun je hem wel als 'betrouwbaar' aanmerken.

[Countess]

met fysieke toegang is elke Windows machine over te nemen.

bij Windows is het een feature dat je met een boot cd het wachtwoord kan resetten en zo
toegang kan krijgen, bij linux is het een bug.

[Skinkie]

init=/bin/sh
mount -o remount,rw /
passwd

...je punt is?

[bzerk]

Dat kan alleen als je geen password op de bootloader (meestal grub) zet. Booten van CD kun je uiteraard in de BIOS uitzetten.
Met deze maatregelen voorkom je dat iemand met "virtuele fysieke toegang" (via ILO of DRAC) de computer over kan nemen.
Tegen werkelijke fysieke toegang (BIOS batterij shorten, disks overzetten in ander systeem) is het bijna onmogelijk je te wapenen.

[FastFred]

Nu moeten linux gebruikers ook aan de antivirus!

[84hannes]

Dus in plaats van de nieuwe updates te installeren installeren adviseer jij een programma op je PC te draaien dat bij elke bewerkign controleert op vooral bekende veiligheidslekken. Lijkt me geen succes voor de performance.

[ChaoZero]

euhm, nou, nee.

Nog voordat er iets gescanned kan worden (dus tijdens de initialisatie van de drive, direct na het aansluiten) is deze buffer-overflow al gebeurt. Om de scan uit te laten voeren moet er een 'te scannen locatie' worden ingevoerd.

Als deze locatie te vinden is in het systeem, is de schijf dus al geinitialiseerd (nieteens gemount!) en het lek reeds misbruikt. In andere woorden: de scan engine is afhankelijk van de Caiaq-usb-driver-module.

nog kort over windows vs linux:
Zowel Windows als linux (als ook OSX) hebben deze probleempjes (lees: buffer-overflow-vulnerabilities). Kijk bijvoorbeeld naar de bug in de rpc-service in windows (het hele conficker-verhaal).
Het mooie van opensource is echter dat deze bugs makkelijk gevonden, aangetoond en verholpen kunnen worden. In closed-source programmatuur is het in de code rondneuzen naar foutjes natuurlijk minder makkelijk, en dergelijke bugs worden dan ook minder snel ontdekt.

apt-get update && apt-get upgrade had dit probleem al in februari (voordat het hier in het nieuws kwam) verholpen. clamav is (bij mij) dus nog steeds alleen nodig voor emails en data voor windows-gebruikers

[Reactie gewijzigd door ChaoZero op 24 juli 2024 07:14]

[Verwijderd]

Het mooie van opensource is echter dat deze bugs makkelijk gevonden, aangetoond en verholpen kunnen worden.

Jaja, maar het mes snijdt wel aan 2 kanten vriend:
re-phrase:

Het mooie van opensource is echter dat deze exploits makkelijk gevonden kunnen worden, je kan de code immers zo inkijken!

[thechronic]

Ja dat denken wel meer mensen. Maar in de praktijk zie je dat veiligheidsproblemen in Linux veel sneller gevonden en verholpen worden.

[Noxious]

Ik zie niet in wat een antivirus aan een brakke driver en een fysieke usbstick doet hoor.

[Oeroeg]

Een fysiek slot op je USB-poort?

[Verwijderd]

Inderdaad. Geen enkel OS is 100% veilig uiteraard.

[blouweKip]

Gelukkig blijft het over het algemeen bij zit soort exploits, en kun je er (itt tot commerciele operating systems) zelf wat tegen doen.
Maar idd, mensen die denken dat er 100% onfeilbare software is die hebben oogkleppen op.

[kidde]

Tja, ik weet het idd niet; er is een reden dat er in vliegtuigen geen airbags zitten! En al helemaal dat die er niet los bij de ingang bij verkocht worden.

[Blokker_1999]

Elke slimme gebruiker heeft op al zijn systemen een AV staan.

[Verwijderd]

mwah... ik niet. Ik haat anti-virus software, ze maken je machine bloated.

Ik heb thuis een zeer scherp afgestelde firewall, op elke PC browsers in een sandbox en maar 1 persoon met rechten om applicaties te installeren (c'est moi! )

Das niet 100%, maar behoorlijk veilig, ik heb al jaren geen virussen meer gehad.
(en ja ik scan de boel wel eens per maand, maar heb geen standaard anti virus suite draaien)

[hackerhater]

En zelfs als het onder WINE zou werken kan je het zo afschieten gezien WINE een user-process is. En automatisch opstarten met de machine zal nooit werken

[djexplo]

Tijd om de hele linux-source eens te porten naar D of Cyclone, dan heb je in 1x alle code beschermt tegen buffer-overflows ten koste van een klein stukje performance.
http://en.wikipedia.org/w...28programming_language%29
Een OS die dit al heeft gedaan:
http://en.wikipedia.org/wiki/AuroraUX

[Reactie gewijzigd door djexplo op 24 juli 2024 07:14]

[Dreamvoid]

Daarom ook sturen OS bouwers de applicatiedevs langzaam aan richting managed code omgevingen als Java/Dalvik/.NET/LLVM/Air/etc, waar je geen buffer en stack overflows meer hebt.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 07:14]

[kidde]

Wel een beetje oldschool, die 'high level languages': Laatste OS dat in high level was, was de voorloper van UNIX vziw. Wel lachen, dat zoiets dan toch na ~50 jaar weer terug komt!

[FireDrunk]

Cyclone attempts to avoid some of the common pitfalls of C, while still maintaining its look and performance. To this end, Cyclone places the following limits on programs:

NULL checks are inserted to prevent segmentation faults
Pointer arithmetic is limited
Pointers must be initialized before use (this is enforced by definite assignment analysis)

En dus crashen de programma's ipv dat ze misschien onveilig zijn...

Leuk voor je printertje thuis die je wil aansluiten, en je os zegt, kernel panic: "Weet je wat, dikke vinger met je printer!, ik ga uit!"

[Reactie gewijzigd door FireDrunk op 24 juli 2024 07:14]

[tweakerbee]

Het is ook niet voor je thuis PC, maar voor die belangrijke server. En ja, die kan er beter met kernel panic uitknallen dan compromised zijn.

[kidde]

Aha, kijk, en daar is Minux voor: Dan kan een kernelmodule duizenden keren crashen (omdat de code random verandert) en draait de kernel gewoon door

Want tja, een auto stopt toch ook niet met rijden als de verwarming kapot is? Linux helaas wel als een driver zuigt. Maar het is wel de meest werkbare oplossing op dit moment natuurlijk. Toch hoop ik dat Minix en consorten een lans breken om de 'binneste kernel' te beschermen tegen drivers, want ook uit dit voorbeeld van 'caiaq' blijkt maar weer dat 80% van de uitbaatbare kernel-fouten in drivers zitten (is ook bij Windows schijnt).

[tweakerbee]

Bij Windows draaien veel drivers ook al niet meer helemaal in kernel space. Bijvoorbeeld een display driver volgens WDDM kan rustig crashen. Je scherm wordt even zwart terwijl de driver herstart, maar daarna kun je gewoon verder werken.

[PPie]

En is dat beter dan een buffer overflow, daarmee je disk driver corrupten en dan enige tijd later je de data op je HD verknallen?

[Antipater]

Ja, dit is wel les 1 in stabiele programma's schrijven: als je een bug constateert moet je onmiddelijk crashen, geen excuses. Niet crashen betekent: anything goes.

Stabiel programma + usb bug: dikke vinger ik ga uit. Jammer, reboot en dag met je stick, verder niets aan de hand.

Onstabiel programma + usb bug: werkt lekker door en formatteert onderstussen al je harddisks...

[mae-t.net]

Je hoeft niet te crashen, je OS kan gewoon dat programma afschieten en verder gaan. Uitgaande van een beschermd geheugenmodel natuurlijk, zie ook DEP onder Windows (zit in de modernere processoren ook gewoon hardwareondersteuning voor dacht ik toch).

[Reactie gewijzigd door mae-t.net op 24 juli 2024 07:14]

[bzerk]

Het programma is in dit geval de kernel zelf. Dus wel degelijk een crash (panic).

[Cyw00d]

Was de wereld maar zo zwart-wit, heb jij die hele Wiki pagina wel gelezen?
Ik citeer van de Cyclone Wiki:
[quote]
This tells the Cyclone compiler that the argument to foo should never be NULL, avoiding the aforementioned undefined behavior. The simple change of * to @ saves the programmer from having to write NULL checks and the operating system from having to trap NULL pointer dereferences...
[quote]

Oftewel Cyclone introduceert een nog strengere C-compiler, zodat je tijdens compilen meer fouten op je bord krijgt die anders in latere versies als bug worden afgedaan.
Je hebt gelijk dat door bounds-checking de hele applicatie kan crashen als hij deze fout detecteerd, maar dat heeft 2 voordelen:
- Je loopt geen geheugen te veranderen waar je niet mag zijn. Waardoor je applicatie gedrag gaat vertonen die onverklaarbaar is.
- Je kan je applicatie nog sneller verbeteren (debuggen)

[Robtimus]

Dit is toch wel een basic programmeerfout zeg. strcpy errors komen al jaren voor, je zou toch denken dat men al sinds de eerste strcpy gerelateerde bug zou zijn overgestapt op varianten als deze strlcpy of strncpy?

[sfranken]

Is men inmiddels ook, kernel 2.6.38 gebruikt stricpy

[LollieStick]

De bug is gefixed vanaf 2.6.37.2. Alle voorgaande versies zijn vatbaar. Het is dus inderdaad vanzelfsprekend dat 2.6.38 niet vatbaar is, maar deze is nog niet stable.

2.6.37.2 is wel stable en is dus de eerste stabiele versie die dit probleem niet heeft.

[humbug]

Wat raar dat jij die basis programmeer fout dan niet eventjes uit de complete Linux code hebt gehaald.... Search en replace toch?

[.oisyn]

Nou is het wel iets ingewikkelders dan dat (je moet immers ook een lengte meegeven, dat moest voorheen niet), maar IceManX heeft gewoon gelijk - dit ís een basis programmeerfout. En waarom is hij verwantwoordelijk voor de fixes in linux code? Hij zal wel wat beters te doen hebben.

[Robtimus]

Ik zeg niet dat het snel op te lossen is, maar wel dat elk stuk software dat zeg maar de afgelopen 3 jaar uitgebracht is op de hoogte moet zijn van de problemen die strcpy (en zo nog een aantal functies) oplevert. En dat betekent dus dat in principe iedereen zijn eigen code allang gefixt zou moeten hebben - niet van de een op de andere dag, maar buffer overflow errors zijn al behoorlijk oud, en toch blijven een aantal programmeurs er niet op controleren. Dat is een kwalijke zaak.

En zoals .oisyn al zegt is search en replace niet zo eenvoudig, maar een eenvoudige search wel degelijk (find + grep = resultaat). Daarna is het helaas handmatig regel voor regel fixen, vanwege de length parameter.

[_JGC_]

GCC geeft iig al een warning als je nu nog strcpy gebruikt, maargoed... wie bekijkt tegenwoordig nou warnings? Weet niet of je wel eens iets als Firefox of OpenOffice gecompileerd hebt, maar welke compiler je ook probeert, die pakketten gaan echt niet compilen met -Werror in de CFLAGS.

[rvannieuwpoort]

Ik snap eigenlijk niet dat men niet gewoon een rgrep op strcpy doet, en ze structureel allemaal vervangt door een veilige variant. Eigenlijk is het gebruik van de standaard strcpy vrijwel altijd een veiligheidsrisico. Zelfs als je weet dat de lengte van de string in de buffer zou moeten passen is het beter om iets als strncpy te gebruiken. Zoals mijn docent vroeger altijd al riep: defensief programmeren!

[johnkeates]

Zelfde verhaal als hierboven: strcpy vervangen door strlcpy is een van de vele opties! En zeker niet de enige of de meest veilige.

[Verwijderd]

sorry hoor, maar als je al fysiek toegang hebt is een standaard machine al practisch weerloos. Daarom, bij server hardening hoort ook het dichtgooien van usb/cd etc.

[Verwijderd]

Daar ben ik het dus in de meeste gevallen niet mee eens.
Hoe ver moet je gaan met server hardening?

USB standaard dichtzetten. De kans dat je er alleen maar hinder van gaat ondervinden is zo levensgroot...tegenover een uiterst miniem veiligheids voordeel.....van dat er misschien ooit een exploit zou kunnen zijn voor een device die niet van buiten af is te benaderen.

Daarbij, van de week moest ik nog een dongle installeren in een server. Via USB dus.
Leuk als jij die dan had uitgezet.

Je kan oneindig doorgaan met beveiligen.
Op een gegeven moment moet je een balans vinden tussen werkbaar en "veilig genoeg". En hoe veilig iets moet zijn, dat is wel afhankelijk van de data.
Zo kan ik me indenken dat de eisen aan een transactie server voor een bank alles op alles wil stellen en in dat geval is bijna geen enkele beveiliging te gek.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:14]

[kidde]

Nogmaals, fout zit in USB sound, niet in USB! Zoek je kernel source er maar op na.

(/usr/src/linux/sound/usb/caiaq, maar svp. niet aan Linus vertellen, die krijgt een hartaanval als die hoort dat mensen hem nog steeds in /usr zetten!)

Beetje slordig van Tweakers lijkt me.

[PPie]

het dichtgooien van usb/cd etc

Waarom zou je dat doen? Als de persoon al bij de machine staat, ben je toch al verloren...
Nu maak je het alleen maar moeilijk voor de legitieme support mensen.

[buzzin]

Een echte server hangt in een afgesloten ruimte met als last resort een slot op rack, server en KVM paneel.
Als een inbreker zo ver is als de USB poort = Machine is verloren.

Het aflsuiten van USB/CD is alleen maar vervelend en alleen een oplossing voor non-profs

[Verwijderd]

Er schijnen ook mensen op de wereld te zijn die Linux op de desktop gebruiken. En daarbij is het niet zo handig als de usb/cd/dvd e.d. niet meer bruikbaar zijn.

[ameesters]

hahaha en dan een grapjas met een pen of een ander dun voorwerp even je reset/uit knop 20 seconde ingedrukt houden door de rack deur heen, of even kortsluiting maken!

Maarje, ze konden in ieder geval niet in je usb/cd, waarbij je je usb toch niet laat automounten en je cd/dvd achter je frontje zit opgesloten, en alleen met een sleutel op krijgt...

[Wolfos]

Hoeft de gemiddelde gebruiker dus niet bang te zijn, want er moet fysiek contact met de computer zijn. Bij bedrijven zal dit anders zijn.