Onderzoeker vindt vier beveiligingsproblemen in driver Linux-kernel - update

Een beveiligingsonderzoeker heeft vier bugs gevonden in een niet standaard meegeleverde driver in de Linux-kernel. Daardoor kunnen kwaadwillenden via speciaal geprepareerde netwerkpackets de driver laten crashen, wat resulteert in beveiligingsproblemen.

Beveiligingsonderzoeker Jason Donenfeld, die de bugs ontdekte, doet het beveiligingsprobleem uit de doeken op de mailinglijst van de Linux-kernel. Het gaat om beveiligingsproblemen in de ozwpan-driver in de Linux-kernel, die ervoor zorgt dat via wifi met usb-apparaten kan worden gecommuniceerd. De driver wordt standaard niet meegeleverd: gebruikers moeten hem zelf installeren.

Met speciaal geprepareerde pakketjes kan een aanvaller een packet of death sturen, waarmee de bewuste driver crasht. Crashes zijn gevaarlijk: dat is het moment waarop een aanvaller in bepaalde gevallen eigen code kan injecteren. Het is onduidelijk of dat in dit geval ook zo is, maar onderzoeker Donenfeld bestempelt zijn gevonden bugs in ieder geval wel als beveiligingsproblemen.

Om beveiligingsproblemen met de ozwpan-driver te kunnen misbruiken, moet een aanvaller zich wel op hetzelfde wifi-netwerk als zijn slachtoffer bevinden. Volgens Donenfeld zijn er nog meer problemen met de ozwpan-driver, die hij nog niet nader heeft kunnen onderzoeken. Zo wordt de lengte van bepaalde parameters niet goed gecontroleerd; dat kan ervoor zorgen dat een aanvaller toegang krijgt tot het geheugen.

Update, 11:53: Verduidelijkt dat het om een driver gaat die niet wordt meegeleverd.

Reacties (40)

Dit nieuwsbericht laat het allemaal heel wat ernstiger klinken dan dat het daadwerkelijk is. Het gaat hier om een zeer specifieke driver die vrijwel niemand zal gebruiken. Het is bekend dat er technische problemen mee waren dan wel dat er geen maintainer voor was, omdat de driver zich in de staging tree bevond van de kernel. Dit zijn drivers die in principe niet gebruikt worden, tenzij je hele goede redenen hebt om dat wel te doen. Doe je het wel krijg je een paar hele dikke waarschuwingen van dat je jezelf op onbekend terrein begeeft.

Zover ik weet is er geen mainstream disto die deze driver standaard mee levert. Installeren kan je het al gauw, maar of mensen dat ook daadwerkelijk doen acht ik al klein, laat staan gebruiken. De gevonden problemen zijn zo op het oog wel ernstig, maar de kans dat een gebruiker er mee te maken krijgt schat ik in als zeer miniem.

100% akkoord het artikel is ook zeer tendentieus er is geen beveiligingsprobleem gevonden in de kernel maar in 1 driver die zelfs standaard niet is enabled.

100% akkoord het artikel is ook zeer tendentieus er is geen beveiligingsprobleem gevonden in de kernel maar in 1 driver die zelfs standaard niet is enabled.

Jullie hebben gelijk. TIFU. Ik heb het verduidelijkt.

WiFI Direct wordt toch in vrij veel apparaten gebruikt en ik vraag mij af of dit Android devices ook zal treffen, dan hebben we het waarschijnlijk over een heel grote groep apapraten die gevoelig zijn.

Omdat het een uitzondering is er en weinig fouten in gevonden worden moet die ene die er doorheen komt sensasineel gebracht worden zonder al teveel context wat de impact eigenlijk is. (vergelijkbaar met de OSX berichten).

Zelfs dan moet de aanvaller op hetzelfde WIFI netwerk zitten om een aanval te kunnen uitvoeren. Het daadwerkelijke gevaar is hierdoor praktisch verwaarloosbaar; zelfs als je de driver hebt geïnstalleerd. Bovendien is er vrij simpel achter te komen wie de schuldige is.

Meer informatie is hier te vinden; http://seclists.org/oss-sec/2015/q2/432

Niet best, hoewel ik me afvraag of deze driver op bijvoorbeeld server installaties aanwezig zal zijn.

Ik snap alleen niet hoe je tijdens een crash code kan injecteren? Of wordt er een speciaal programma actief bij een crash oid?

Inderdaad onwaarschijnlijk omdat een server ook bijna nooit aan een Wifi netwerk hangt.

Zou toch redelijk standaard moeten worden voor een programmeur om ervanuit te gaan dat alle data die je binnen krijgt malifide is en dus voldoende gecontrolleerd moet worden voordat je ermee aan de slag gaat.

Zou toch redelijk standaard moeten worden voor een programmeur om ervanuit te gaan dat alle data die je binnen krijgt malifide is en dus voldoende gecontrolleerd moet worden voordat je ermee aan de slag gaat.

Hiermee impliceer je dat driver ontwikkelaars altijd weten wat ze aan het doen zijn.

Maar even zonder gekheid, programmeren op driver/OS niveau is wel wat anders een web service of web applicatie bouwen. Je hebt ten eerste met niet-human-readable protocollen te maken, en protocollen zijn vaak wat vaag of helemaal niet gedefinieerd. Daarnaast werk je met een programmeertaal die jou niet bij de hand neemt en soms constructies vereist waarover moeilijk te beredeneren valt, en dus het risico creëert dat er foutjes in zitten. Ten slotte wat ik grappend noemde is toch vaak nog waar. Driver ontwikkelaars werken soms met compleet onbekende of nieuwe technologieën. Ik kan mijn docent erop quoten dat "embedded development vaak toch een beetje prutswerk is".

Er is helemaal niets speciaal aan embedded of Linux kernel.
Tuurlijk zijn er wat verschillen (memory management, geen libc, meer constrained omgeving, ...) maar het is en blijft gewoon C-code. Dat sommigen deze constraints aannemen om te lopen klungelen en klooien is hun zaak.

De fouten hier lijken gewoon op carelessness enerzijds en onvoldoende begrip van de basic C integer types. De developer is een Atmel werknemer en H/W bedrijven staan er nou niet om bekend om goede code af te leveren (zie Samsung als groot voorbeeld)

Er zullen inderdaad weinig servers met wifi zijn. Echter gebruiken veel fabrikanten ook linux voor hun accesspoints en routers met wifi. Hier is de kans groter dat deze code aanwezig is.

Dan nog moet de kwaadwillende op hetzelfde WIFI netwerk zitten; de exploit werkt niet vanaf een extern IP.

Dat kan op verschillende manieren (buffer overflows, null pointer dereference). Het is zelfs zo dat veel exploits ook als DoS gebruikt kunnen worden.

Meestal wanneer een programma segfault is dat omdat je programma wou springen naar een ander memory address dat oftewel niet valide was (niet gemapped in address space) of niet uitvoerbaar was (NX). Als je dan nog kunt beinvloeden naar welk memory address je kan springen (buffer overflow) heb je prijs.

Zowel op mijn router als op mijn PC. Ik denk dat het nog wel 10 of 20 jaar gaat duren voordat het handig is, of nodig is, om het weer aan te zetten.

De driver zit standaard niet in de kernel dus over je servers hoef je je geen zorgen te maken. Tenzij je zelf moeite hebt gedaan om die driver te installeren en dan zou je het wel weten.

Ik snap alleen niet hoe je tijdens een crash code kan injecteren? Of wordt er een speciaal programma actief bij een crash oid?

Ik ken deze specifieke bugs niet maar typisch werkt dat in twee trappen. Eerst zorg je dat je code op het systeem komt. Dat kan via een bug zijn maar ook door hem domweg te uploaden via de webserver op dat systeem of iets dergelijks.
Vervolgens laat je de driver crashen op een manier dat hij jouw code inlaadt.

De kunst zit er in dat je de moet voorspellen wat die crashende driver gaat doen en er voor zorgen dat je daar richting aan kan geven en dat jouw eerder geuploade code precies op de juiste plek staat.

Hmm dat uitventen van potentiele security-bugs neemt ook een aardige vlucht.
Er wordt tegenwoordig haast langer op de catchy naam van een security-bug gestudeerd dan op de code zelf. In dit geval gelijk ook maar een stapel individuele CVE's willen .. vast voor z'n CV.

edit: for havens sake .. het is nog een driver in "staging" ook, kortom drivers die eigenlijk nog niet aan de kwaliteitseisen voldoen, maar waarvan gehoopt wordt dat het de ontwikkeling bespoedigd door het in-kernel te doen en het makkelijker te maken voor potentiele gebruikers van soms nieuwe hardware dan een out-of-tree module.

[Reactie gewijzigd door gekkie op 14 mei 2015 11:10]

Tja, marketing doet wonderen he.
Het is haast alsof mensen door zijn geslagen in het "romantiseren" van dat hele hacker gebeuren; en nu ook maar gaan richten op catchy namen die iedereen zal onthouden. Lekker belachelijk. Focus gewoon op het probleem, en los het op.

Yups .. heb er zelf eentje gewoon gemeld .. met nog de mededeling dat ik het mezelf af vroeg of het er wel een was .. aangezien het voornamelijk een information leak zou kunnen zijn. Maar het was nou nog niet echt in me opgekomen om er een POODLE, BEAST, VENOM of iets dergelijks van te maken ... een persbericht naar alle media uit te doen gaan .. en eerdags de vlag te hijsen.

Maar goed als je explort niet in een bounty-programma zit .. kun je er maar op 2 wijze nog iets aan verdienen ... of the dark path ... of wat roem vergaren .. dus eigenlijk is het nog het meest onschuldige.

Ik denk dat het risico wel meevalt als de aanvaller op hetzelfde wifi netwerk moet zitten, als je een goede beveiliging thuis hebt opgezet is de kans dan miniem. In het geval van gebruik van openbare netwerken kan je de driver tijdelijk disablen lijkt me dan dat je veilig bent voor dit soort aanvallen.

De meeste inbraakgevallen zijn "inside jobs". Zoals je als ICT-er wel zult weten dienen tegenwoordig ook systemen die alleen maar binnen een bedrijfsnetwerk te bereiken zijn ook aan de hoogste security requirements te voldoen.

Layer 2 dus kan het niet via het internet uitgebuit worden.

Mischien begrijp ik het niet hoor, maar dan moet die betreffende kernel module wel geladen zijn. Het zou dan te checken zijn met lsmod (bv lsmod|grep ozwpan) en dat laat bij mij in ieder geval niets zien (Arch Linux).

Ik heb nog even gezocht maar ik kon zo snel niet vinden of er distro's zijn waarop dit wel standaard geladen wordt. Op Debian 8 en CentOS 7 kan ik ook geen spoor van deze module vinden.

Ik denk dat het bericht het ernstiger laat klinken dan het is en dat het een module betreft die standaard niet gebruikt wordt.

[Reactie gewijzigd door InflatableMouse op 14 mei 2015 10:46]

stm laat in zijn reactie duidelijk zien waarom. De driver zit in de staging tree en heeft geen maintainer. Deze word dus niet in de mainline kernel opgenomen.

Alsof windows nooit een beveilingsprobleem heeft gekend ...

Geen enkel OS is vrij van fouten, het is belangrijk hoe ze er mee omgaan. In dit geval gaat het om een driver die standaard al niet aanwezig is en waarvoor je als gebruiker moeite moet doen om hem in je kernel te krijgen. Het risico ligt hier dus helemaal bij de gebruiker, net als in windows waar exotische drivers ook door de gebruiker zelf moeten geladen worden.

Alsof windows nooit een beveilingsprobleem heeft gekend ...

Heb ik ook nooit beweerd. De "neurten" slaagt trouwens op beide Windows en Linux aficionados.

Geen enkel OS is vrij van fouten, het is belangrijk hoe ze er mee omgaan. In dit geval gaat het om een driver die standaard al niet aanwezig is en waarvoor je als gebruiker moeite moet doen om hem in je kernel te krijgen. Het risico ligt hier dus helemaal bij de gebruiker, net als in windows waar exotische drivers ook door de gebruiker zelf moeten geladen worden.

Ben ik 100% akkoord mee. En beveiligingsfouten vinden en oplossen is een noodzakelijk onderdeel van het process van beveiliging.

Linux en FOSS daarentegen, voeren de boventoon als het gaat om beveiligingslekken.

Omdat de media er deze tijd maar al te graag op springt en de FOSS gemeenschap hun bugtrackers/repos/development procedures niet afschermt dus makkelijk voer geeft voor een hype. Zoals al gezegd dit gaat om een staging (beta) driver die geen maintainer meer heeft. Als deze situatie zo blijft kan het goed zijn dat deze driver binnen een paar releases zelfs niet meer in de staging dir zit. (http://www.kroah.com/log/linux/linux-staging-update.html)

Windows is een veel groter target, dat de bugtrackers/repos/gits etc. open staan van FOSS producten zegt niet alles. FOSS krijgt wat meer de aandacht van "Is het ook veilig" sinds een jaar of wat, en vrijwel elke week lees ik weer iets nieuws in de FOSS wereld wat wijdgebruikt wordt en lek blijkt te zijn.

Overigens is al vele jaren de Windows en NT broncode ook door mensen in te lezen. Niet publiekelijk natuurlijk. Maar overheden, universiteiten e.d. kunnen inzage krijgen in de broncode.
Heeft ook geen explosie aan veiligheidslekken veroorzaakt.

Dit is inderdaad niet zo'n boeiende exploit omdat er weinig (geen?) (grotere) distro's zijn die het er in hebben zitten. Maar het is er _weer_ 1.

Overigens is al vele jaren de Windows en NT broncode ook door mensen in te lezen. Niet publiekelijk natuurlijk. Maar overheden, universiteiten e.d. kunnen inzage krijgen in de broncode.
Heeft ook geen explosie aan veiligheidslekken veroorzaakt.

Zeker dat dat niet door de NDA komt ? Tevens vergelijk je hier Windows met FOSS. Als je eerlijker wilt zijn moet je ook andere Closed source software in de vergelijking mee opnemen of je beperken tot de kernel en een subset van userspace.

Alsof een NDA dat zou tegenhouden. Er zullen er meerdere zijn die met hulp van de broncode gebouwd zijn de afgelopen jaren.

De meeste van de FOSS wat in het nieuws komt wordt meegeleverd met o.a. Debian. Hetzij via de repos van een distro.

Dat vergelijken met Windows en zijn miljarden .exe's en de store als de repos, lijkt me eigenlijk best redelijk. Kan met niet heugen hoe lang het geleden is dat 1 of ander malware exe de rest van Windows heeft weten te infecteren. (Zonder UAC, WD, EMET e.d. uit te schakelen).

Gevalletje 'perceptie' en 'realiteit'...

Volg even mee:
Start > Control Panel > Windows Update > View Update History
14/5: 12 van de 16 updates zijn security updates
18/4: 9 van de 15 updates zijn security updates

Hoezo windows is meer secure dan Linux en FOSS software?
Het lijkt er eerder op dat er een heksenjacht is op FOSS.

Anderzijds zijn er wel problemen met enkele packages... Veel bedrijven (inclusief multi-million-dollar) gebruiken FOSS uitgebreid maar help te weinig met die software te onderhouden of secure te houden/maken.
Daar lijkt nu gelukkig op enkele vlakken wat beweging in te komen.

[Reactie gewijzigd door H!GHGuY op 14 mei 2015 13:31]

Het lijkt er eerder op dat er een heksenjacht is op FOSS.

Ik denk meer een groei in de security-business, met daaraan gekoppeld een uitbreiding van de "marketing" van je gevonden exploit. Catchy naam, enige overdrijving van de impact etc.

Linux kernel

geen prijs bekend

Waarom staat dat daar?

geen id. automatisch denk ik staat bij elk bericht valt me op, foutje op tweakers site.

[Reactie gewijzigd door itcouldbeanyone op 14 mei 2015 14:10]

Dit bericht gaat indirect over de Linux kernel, en dus wordt dit 'product' aan de rechterkant getoond. De kernel heeft echter geen prijs, dus die is onbekend. Kan inderdaad wat netter opgelost worden, maar echt storend vind ik het ook niet.

In plaats van "geen prijs bekend" zou er "onbetaalbaar" moeten staan

priceless

Beetje vreemd dat de kernel een 'product' is... Het is niet iets dat je kunt kopen, of gebruiken als ieder ander product. Het is eerder een onderdeel, maar een onbekende prijs is natuurlijk raar, want de kernel is vooralsnog gratis.