Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door Dimitri Reijerman

Redacteur

08-03-2011 • 14:36

164 Linkedin Google+

Reacties (164)

Wijzig sortering
Als iemand fysiek toegang heeft tot je computer ben je sowieso de sjaak, dan kan iemand er mee doen wat hij wilt, usb exploit of niet.
Als iemand fysiek toegang heeft tot je computer ben je sowieso de sjaak, dan kan iemand er mee doen wat hij wilt, usb exploit of niet.
Iemand hoeft geen fysieke toegang tot je PC te hebben om te zorgen dat je z'n USB stick in je eigen PC steekt. Wat bijvoorbeeld wel gedaan wordt is dat de hacker een USB stick laat slingeren op een plek waar z'n slachtoffer hem waarschijnlijk zal vinden. Vervolgens hoeft hij alleen maar te wachten tot het slachtoffer nieuwsgierig wordt naar wat er op die stick staat.

Zo is bijvoorbeeld de stuxnet worm op PCs terechtgekomen die niet met het internet in verbinding staan.
Dit probleem is overigens al langer bekend! Ze zijn momenteel bezig bij 1 van de projecten (welke weet ik niet? --> App-armor, SElinux, LIDS) om alle buffer overflows te redirecten naar een soort van hoofdbuffer, die hoofdbuffer stelt daar de prioriteit in en mocht het echt nodig zijn dan schakelt hij het patroon uit. Hoe dit precies zit weet ik ook niet, maar heb er een stukje van gelezen.

Dit ging overigens voornamelijk om buffer-overflows van browsers, maar ze wilden later ook software en hardware aan gaan pakken.
Dat werkt fundamenteel niet met "alle buffer overflows". Stel je voor dat ik een buffer heb voor de volgende data: USB_DATA (naam = 80 bytes, type = 2 bytes). Nu lees ik de naam van zo'n gehackt USB device af. Daar staat een naam van 82 bytes op. Dat past in zo'n USB_DATA buffer, maar het overschrijft wel het "type" veld.

Een tweede omzeiling is dat het goed mogelijk is dat USB_DATA als type 84 of 88 bytes is, omdat de grootte op een veelvoud van 32 of 64 bits wordt afgerond. Dan reserveert malloc genoeg ruimte, en zal de buffer beveiliging niet protesteren als je ook 84 bytes wegschrijft. Maar dan heb je dus 2 bytes in een naamloos veld verstopt.
Klopt maar ook daar hadden ze een plan voor
Ow dit gaat de Linux haters weer voeren....

Technisch gezien is een dergelijke fout natuurlijk zo gemaakt. Dat er iemand ontdekt dat je dit kunt 'misbruiken' is twee.

Vraag me af hoeveel onbekende dingen van soortgelijke aard in Linux/Windows zitten... maar het zullen er best nog wat zijn.
Zo blijkt maar weer dat het grootse probleem op gebied van computer security gewoon human error is. Als dit deel grondig volgens de beschikbare theorieen was getest dan had dit voorkomen moeten worden, maar mensen maken natuurlijk fouten en gaan niet altijd even systematisch te werk. Een systeem is zo zwak als de zwakste schakel, of dat nou Windows, Linux, iOS, Mac OS X, Solaris, BSD, Android, of een proprietair systeem, of iets anders is.
Duh alle computersystemen zijn door mensen gemaakt, het is dus per definitie human error ;)
Nog wel ja, maar is het ook human error als intelligente computerprogramma's code gaan schrijven? Ergens is dat dan namelijk ook indirect door mensen gemaakt :P
Computers merken hele andere dingen dan jij. Daardoor kan jij een security fout zien die een computer niet ziet. Voorbeeldje;

Je koopt een fiets (artikelnummer 123) voor 800 euro online. Je gaat naar het betalingsschermpje, en je ziet de volgende url;

http://www.shop.com/betalen.php?artikel=123&prijs=800

Goh, hoe zou je dit toch eens stevig kunnen misbruiken...

JIJ ziet dit, een computer ziet gewoon een string die met een GET commando wordt binnengehaald... even controleren of er geen code tussen zit, maar verder zal het wel veilig zijn (volgens de computer dan).

[Reactie gewijzigd door damnyankee op 8 maart 2011 17:00]

Maar een computer kan in dit geval niet weten welke data een gebruiker aan mag passen.

Dat artikelnummer zo in de URL zetten is geen probleem. Dat mag de gebruiker ook best aanpassen, ik mag toch zelf weten welke fiets ik koop?

Alleen de prijs moet de server zelf adhv. het artikelnummer opzoeken. Die moet je niet door de gebruiker aan laten leveren: never trust user input.

Technisch gezien kan de URL die je laat zien best veilig zijn, het zal de fietsenboer alleen vast veel geld kosten. Stel echter dat dit zou gaan om de pay-what-you-want humble indie bundle of een donatiewebsite ipv. een fiets, dan zou dit weer perfect acceptabel zijn.

Ook met een "veilige" webshop kan je natuurlijk nog altijd de verkoper naaien. Bestel 5000 producten, of bestel iets zonder ooit te betalen. Geeft ook overlast.

Ander voorbeeld is denk ik beter, stel je hebt het volgende:

www.mailinglist.kom/nieuwsbrief.php?brief=maart&mailadres=003

Op de pagina kan je je eigen mailadres zien. Een computer zal hier waarschijnlijk geen kwaad in zien (het werkt toch prima en je hebt toch alleen je eigen nummertje?), maar je kan zo wel heel makkelijk mailadressen van de lijst gaan harvesten.

[Reactie gewijzigd door Mentalist op 10 maart 2011 01:32]

Een computer zal dit soort fout heus wel opmerken in zijn unit testing. Immers naast correcte waarden, wordt ook getest met foute waarden. Tijdens de testfase zou dit voorbeeld falen omdat het verwachte resultaat niet zou overeenkomen met het berekende resultaat.
Dan moet er wel door een programmeur aan gedacht worden om een string met 1 miljoen karakters (of welke andere waarde dan ook groter dan de buffer van 80) te testen.

Ik kan me voorstellen dat men gedacht heeft: volgens de USB RFC mag een device naam niet langer dan 80 characters zijn. Als het volgens de USB standaard niet mag, dan hoeven we niet te controleren op een stituatie die niet voor kan komen.

Zeg niet dat het goed is, wel dat het begrijpelijk is.
Doet me denken aan de (1e) Ariane 5 die explodeerde omdat een variabele op nul stond. De de programmeur had die nul niet afgevangen omdat hij had bewezen dat die variabele nooit nul kon worden, althans op de Ariane 4.

Soms is het zinnig dingen af te vangen waarvan je weet/verwacht dat je niet kunnen gebeuren, alleen weet je nooit goed wanneer dat zinnig is of niet.
Je zou ervoor kunnen zorgen dat alleen bepaalde GET waardes door de gebruiker mogen worden gegeven, een rechten systeem op variabelen.

Het bestaan van een URL zoals jij geeft is overigens nog steeds human error, aangezien een persoon het systeem zo gebouwd heeft dat de prijs een gebruikersvariabele is geworden.

Ach ja, gewoon geen stomme fouten maken (zoals een buffer overflow niet tegengaan).
Of je ai maakt geen links uit het jaar 1995 zoals een idiote mens wel nog zou doen...
Nee, dit is geen human error. Als het een human error was geweest dan waren het andere soort fouten geweest dan het kiezen van een verkeerde functie. Het declareren van een strcopy is gewoon heel anders dan een strlcopy:

strcpy (str2,str1);

en

strlcpy(stack_buffer, source, sizeof(stack_buffer));


strlcopy is ook een relatief nieuwere functie(bestaat pas sinds OpenBSD-2.4) dan strcopy wat standaard in de ANSI C library geÔmplementeerd zit.
Bron: http://en.wikipedia.org/wiki/Strlcpy

Ik durf te wedden dan ten tijde van het ontwikkelen van de driver de strlcopy functie niet algemeen bekend was onder ontwikkelaars.
En dat toen het wel zo was het niet zo grondig is doorgevoerd als men dacht. Dit zal hoogstwaarschijnlijk weer even ervoor zorgen dat men wat grondiger door de code gaat kijken.

[Reactie gewijzigd door Typnix op 8 maart 2011 17:11]

Tja zo heb je al jaren meerderen vraianten op strcpy. wstrcpy (welke ook widecharacters aan kan), strncpy, etc. etc. etc. noem ze maar op. Ze doen allemaal hetzelfde, het aantal characters beperken zodat je geen overflow kan krijgen.
En toch zijn zeker (heel ruwe schatting) de helft van alle bugs, ongeacht het OS, bufferoverflows. Kennelijk letten veel programmeurs niet op bij het vak "Programmeren 101" of bij het lezen van het boekje "C voor dummies".
Als dit deel grondig volgens de beschikbare theorieen was getest dan had dit voorkomen moeten worden
Testen op Fout excepties binnen de white box test scoop. Welke theorie is dat?
Dit valt niet binnen de normale white box tests (bv Unit testen)
En met blackbox testen wordt je niet getriggerd op het strcpy-commando.

Alleen het reviewen van de code zal naar de mogelijke fout wijzen. Dat is geen Test theorie Dat is vrije tijd besteding.

BTW Dat een systeem zo zwak is als de zwakste schakel is flauwe kul. Dan zal alles wel een remote root vulnerability zijn
Testen op Fout excepties binnen de white box test scoop. Welke theorie is dat?
Dit valt niet binnen de normale white box tests (bv Unit testen)
Bij unit testing wordt wel degelijk ook ongeldige input voorgeschoteld aan de routine om te controleren dat de routine niets verkeerds doet. In het geval van een functie die een string uit een buffer kopieert zou er minstens testen moeten zijn die de volgende scenarios bevatten:
  • de string is null
  • de string is leeg
  • de string is te lang
  • de string bevat ongeldige karakters
  • ...
Dat de gemiddelde programmeur zoiets niet doet maakt het niet minder fout.

Nu is het wel zo dat de meeste compilers al jaren uitgerust zijn met switches die buffer overruns detecteren at run-time en er voor zorgen dat ze niet misbruikt kunnen worden. Maar ja, dat soort checks introduceert natuurlijk altijd enige vorm van overhead, iets wat je natuurlijk niet wenst in kernel modules. En daarom is unit testing voor dit soort modules veel belangrijker dan voor gewone code.
Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?
vindt t wel cool, als je je pass vergeten bent op een systeem die je niet kan resetten, usb-(vast wel weer een arduino)-key d'r in en : root !! :D..
bref.. de buffer overflows zijn de wereld nog niet uit...


edit: benadrukken (bold) van wat ik schreef... |:(

[Reactie gewijzigd door zeduude op 9 maart 2011 08:32]

Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?
Puristen die een hekel hebben aan monolitische kernels?
Buiten A. S. Tanenbaum waarschijnlijk niemand. ;)
Linux en monolitische kernel hoeft niet synoniem te zijn natuurlijk. De "Everything as a module" mentaliteit zit er toch bij menig distro wel in.
Een beetje purist zou een hekel hebben aan hybride kernels of microkernels...
Stel dat je via USB toegang zou krijgen op kernel niveau, het geeft jou dan dus (nog) geen rootrechten...
Op het moment dat je kernel-level access hebt, heb je alle rechten. Je kunt alle geheugen, inclusief alle security-gerelateerde code en data lezen en schrijven.
Dat zou te makkelijk zijn. Een USB apparaat krijgt door de driver automatisch kernel-level access (I/O), maar dat betekent niet dat je als USB interfacegebruiker super user rechten hebt.
Mensen beseffen zich niet voldoende dat automatisch mounten van apparaten een groot veiligheidsrisico met zich meebrengt. Het hele circus kun je volgens mij omzeilen door de automount voor USB apparaten in fstab uit te zetten. Dit verhindert shell/user level access. Probleem opgelost.
Of je verwijdert de betrokken drivers: . /sound/usb/caiaq/audio.c en ./sound/usb/caiaq/midi.c
Probleem opgelost.
Op zich wel handig, maar het gaat alleen bij systemen met een 'oude' kernel.
Het onveilige strcpy-commando werd pas in februari vervangen door het veiligere strlcpy-commando in de Linux-kernel.
Als je een nieuwere kernel hebt, zou het dus niet meer mogelijk moeten zijn...

Bewijst maar weer dat je altijd up-2-date moet zijn ;)
Dit viel me ook op, ze vinden nu een veiligheidsprobleem dat een maand geleden al opgelost is.

Zo kan ik ook wel veiligheidsfouten ontdekken door in changelogs te gaan speuren |:(
Euhhh... booten in single-user mode en pw veranderen is ook een oplossing....
Euhhh, booten naar single-user mode, vraagt tegenwoordig ook om het root wachtwoord.

Booten van een live cd / usb en dan het wachtwoord aanpassen.

Vanuit gaande dat je de boot volgorde zou kunnen aanpassen ;)
Precies. Als je nog een CMOS / Legacy BIOS systeem hebt kan je dat ook omzeilen met 1 enkele instructie, maar met OpenFirmware of Extended Firmware Interface wordt dat al een stuk moeilijker. En dan is er nog OpenBios en Coreboot waar het helemaal lastig is.

Uiteindelijk hebben we het hier over een exploit die fysieke toegang vereist, en dat is dan helaas een stuk minder specaal. Met fysieke toegang is alles te hacken. Ook bitlocker kan je er heel eenvoudig mee breken.
En dat de gewensten poorten/drives aanwezig zijn. Ik zie steeds vaker dat computers de intellingen hebben om USB mass storage te weigeren en de BIOS ongeautoriseerde drives/kaarten niet accepteert. Kwam dat pas tegen in een HP workstation, die weigert keihard kaarten die niet op de HP whitelist staan.

[Reactie gewijzigd door SizzLorr op 8 maart 2011 19:23]

Dat kan tot dat je zoals ik de groepen hebt aangepast en dan per ongeluk je zelf hebt buiten gesloten (dat is mij 1x overkomen!) Gelukkig is er dan nog 1 weeg en dat is via de grub command line (mits je daar ook geen wachtwoord op hebt gezet! ;) )

Oke het was dom maar wel leerzaam!
en dat de disk niet encrypted is.
Euhhh, kom je gemakkelijk omheen door even "init=/bin/bash" als parameter mee te geven ;)
Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?
Ja, er zitten er zelf een paar op Tweakers.net.
Ik ga maar geen namen noemen ;')

[Reactie gewijzigd door BeosBeing op 10 maart 2011 16:53]

Mja, wees maar gerust, dit soort dingen gaan veel vaker voorkomen. Punt is alleen... deze bugs zijn zwaar overtrokken. Bij de gemiddelde linux (en ook windows en OS X) install kan je met fysieke toegang tot het systeem sowieso wel Administrator of root krijgen. Om deze bugs te exploiten heb je fysieke toegang nodig, en dan nog vraag ik me af of het niet veel makkelijker is om gewoon de CMOS te clearen, van CD te booten en het rootpassword te veranderen.
Maar je heb hier helemaal geen fysieke toegang nodig. Denk maar aan een eBay merchant die usb sticks verkoopt. Die kan dan mooi toegang krijgen tot alle linux pcs waar die stickjes in worden gebruikt.
Precies. Zo was Stuxnet toch ook die kerncentrales in Iran binnengedrongen? Via besmette USB sticks?
Zeer mee eens.

Met fysieke toegang kan je vrijwel elk systeem binnenkomen. Dat maakt dit soort bugs niet goed, maar 'een groot gevaar' is het niet bepaald te noemen. Vooral omdat - in tegenstelling tot wat het artikel beweert - dit in de meeste kernels die in omloop zijn wel gerepareerd is.

Het vinden en patchen van bugs zal hopelijk nog veel vaker voorkomen. Voordeel van linux is dat dit patchen doorgaans zeer snel gebeurt.
Gelukkig is er de nieuwe functie strlcpy() al... dus bij genoeg updates/patches is dit al verholpen. Toch?
so what...............tenzij er door een hacker bij je wordt ingebroken en z'n absurd genaamde USB stick in je PC stopt, ur fine.........ik geloof dat ze minder moeite hoeven te doen voor een hack in een windows PC
Dit heeft niks met genaamde usb sticks te maken. Maar met USB device names. Dit zijn de namen die vaak in een EPROM zijn geprogrammeerd die aan de USB Slave controller gekoppeld zijn.
Okee. Oud nieuws, want dit gat was in februari al dicht.

Voor alle bug-lievende mensen out there: niet iedere bug is een bug. Soms is het een eigenschap van de interface. Gedrag van code, een lengte van een string, etc. Soms leiden eigenschappen onbedoeld tot onverwachte resultaten, of geheugenfouten, wat dan weer een beveiligings issue kŠn worden - maar niet altijd Ūs.

Want meestal (in dit geval niet dus) is het dus de eigenschap van de interface: bedoeld gedrag. Dan bedoel ik de auto-run functionaliteit, automatisch mounten van volumes, een progje dat automatisch start en je desktop omgeving die jou als gebruiker niet om toestemming vraagt om iets uit te voeren; Bij gebrek hieraan kun je soms bijvoorbeeld achter de screensaver langs het wachtwoord op de screensaver hacken met behulp van een shellscript. Ik roep zo maar eens wat.
Daar komt nog bij dat dit alleen werkt als je zelf fysiek bij het appraat aanwezig bent. Inbreken op afstand is er dus niet bij. Het eerste security issue is dan altijd nog: een goed slot op je deur. 8-)

Naast dat er op de meeste Linux machines allerlei veiligheidsmaatregelen ingebouwd zijn (ASLR, PIE) en er op de machine waarschijnlijk ook wel AppArmor o.i.d. geÔnstalleerd is, kan ik met aan zekerheid grenzende waarschijnlijkheid zeggen dat deze 'gevaarlijke bug' niet op iedere machine zal leiden tot een succesvolle inbraak.
Stel dat je via USB wťl toegang zou krijgen op kernel niveau, het geeft jou dan dus (nog) geen rootrechten. Daarvoor moet je je ook weer in allerlei bochten wringen... dus dan moet je nog wat hacken.

Geloof mij nou maar als ik zeg dat de exploit van deze bug geen garanties biedt. Op veel linux machines hebben auto-parsers weinig kans en niet elk script laat zich pushen.
Er zijn dus een hoop aannames en randvoorwaarden waaraan voldaan moet worden voordat een 'hack' via USB werkt.

Het is veel makkelijker om FireWire te gebruiken als je dan toch direct toegang wilt krijgen tot een machine. FireWire heeft DMA en als je een andere computer verbindt, dan kun je er vrij makkelijk in...
Voor alle bug-lievende mensen out there: niet iedere bug is een bug.
Klopt. Geldt vooral voor Zend, daar is het nooit een bug, want het is immers gewoon hoe zij het hebben ingetypt, en wat ze intypen definieert het gedrag ipv andersom. Tja, dan heb je idd nooit bugs.

Maar dat is hoe prutsers te werk gaan. Dit is gewoon een bug. In kernel-mode kun je je geen fouten als buffer overflows permitteren, en moet je code gewoon robuust zijn. Dat is (was) deze code niet. Een oversight en niet expres, dat snap ik ook wel, maar weldegelijk een bug die gefixed dient te worden (en dat inmiddels al is).

[Reactie gewijzigd door .oisyn op 8 maart 2011 17:34]

Wat mij telkens weer verbaasd in de grotere softwareprojecten (tevens ook vaak open source projecten) is dat de programmeurs ontzettend veel kennis en ervaring hebben en ontzettend mooie oplossingen kunnen creŽren, maar dat dan simpele zaken, zoals het controleren van de lengte van een string vergeten wordt.

Nu is er natuurlijk ook iets voor te zeggen dat zulke overflows moeilijker te vinden zijn bij gesloten systemen dan bij open systemen, zoals Linux, maar het verbaasd mij toch wel!
Mag het een device driver zijn door een bedrijf in de kernel driver tree geplaatst opverzoek van dat zelfde bedrijf
En wederom werpt de pro-actieve code-auditing van OpenBSD haar vruchten af, lijkt me.

"We plan to replace occurrences of strncpy() and strncat() with strlcpy() and strlcat() in OpenBSD where it is sensible to do so." aldus Theo de Raadt. Erg jammer dat de Linux-code kennelijk niet op dezelfde manier ge-audit wordt, maar gezien de grotere omvang misschien ook wel logisch.
Niet dat die wijziging hier on-topic is. Als Linux een strncpy(dest,src, sizeof(dest)); had gebruikt, dan was er hier ook geen buffer overflow geweest. Dan waren er maximaal 80 bytes naar de bufefr gekopieerd. Het probleem is dat strcpy(dets,src) op geen enkele manier de lengte van dest checkt.

De enige "winst" van strlcpy is dat je daarna veilig een strcpy kunt doen. Maar als je codebase zo goed is dat je toch al overals strncpy gebruikte, dan heb je dus geen winst om strncpy te vervangen door strlcpy.
grapjas... sizeof(dest) geeft netjes de grootte van de pointer terug. dus 1, 2, 4 of 8, afhankelijk van de architectuur (8bit, 16bit, 32bit of 64bit) van het systeem. - dat werkt dus niet.

[Reactie gewijzigd door psyBSD op 9 maart 2011 08:14]

Niet als dest een array is. Dan geeft-ie netjes de size in bytes van de array terug.
Usb verijst nog direct acces...

Oftewel Ik voel me er niet minder veilig op :P
The Holy Grail! Zo'n sticky ga ik ook maken, in case als ik me pwd kwijt ben ;-)
En nog steeds is de code dus buggy. Ook nu met strlcpy().

De USB spec is duidelijk. String descriptors zijn length-prefixed. Dat is een verschil met standaard C strings, die eindigen met \0'' (0x00 byte). Het is echter niet compleet ongebruikelijk; Pascal gebruikte wel length-prefixed strings.

Dit betekent dat je string descriptors kopieert met mempcy() (kopieert bekend aantal bytes) in plaats van strcpy of strlcpy (stoppen beiden bij de eerste '\0'). De strlcpy "fix" die er nu in zit voorkomt wel de buffer overflow, maar kan nog steeds random ongerelateerde bytes naar het geheugen kopieren.

[Reactie gewijzigd door MSalters op 8 maart 2011 23:47]

Maar zolang die random ongerelateerde bytes in de daarvoor bestemde geheugenruimte blijven is dat toch geen probleem?
Wordt je USB stickje misschien niet goed herkent... jammer dan.

Ok, netjes en 100% stabiel/veilig is anders, maar met strlcpy is het gevaar wel geweken.
Er zijn nog veel meer problemen in de Linux Kernel te vinden behalve strcpy.

- Het is bijv. mogelijk om via EXT4 root toegang te krijgen
- Er zijn duizenden strings die niet als een constante zijn defineerd, terwijl dit wel zou moeten.
- Een aantal geluidsmodules zijn gevoellig voor buffer exploits.

Het afgelopen jaar heb ik samen met een aantal collega ontwikkelaars de kernel doorgezocht op beveiligingslekken en een groot aantal zullen in de komende kernel versies gefixed worden. Ondanks dat ik redelijk wat zeggenschap heb in de kernel ontwikkeling, zijn we toch afhankelijk van derden om dit uiteindelijk door te voeren en uit te testen.

Een van de redenen waarom bijv. GrSecurity niet toegelaten wordt in de vanilla kernel, is dat dan vele kernel ontwikkelaars hun slechte programmeer gewoontes af zouden moeten leren.

Het is wel schandalig, maar Mac en Windows doen het echt niet veel beter. Gelukkig heb ik al veel van deze beveiligingslekken in de Fortress Linux kernel gedicht, maar er zijn er gewoon te veel.


Het is tevens ook mogelijk om de auto mount en run functie van o.a Ubuntu te misbruiken. Zie dit artikel:

http://www.fortresslinux....attacks_against_Linux.pdf

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True