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

Door , , 81 reacties

Met een nieuwe exploit voor de Linux-kernels 2.6.18 en 2.6.30 blijkt het voor een aanvaller mogelijk om alle beveiligingsmaatregelen te omzeilen. Volgens kernel-co÷rdinator Linus Torvalds is er echter geen sprake van een exploit.

De exploit, waarvan de code vrijdag is vrijgegeven door Brad Spengler van Grsecurity, misbruikt een kwetsbaarheid in de tun-interface in Linux kernel 2.6.30 en 2.6.18, die alleen door Red Hat Enterprise Linux 5 voor testomgevingen gebruikt wordt. De kern van het probleem huist in een null pointer dereference, die te misbruiken is middels de optimalisatiefunctie van de GNU Compiler Collection. De exploit zou het mogelijk maken om root-access te verkrijgen. Het bijzondere aan de exploit is dat deze zelfs ingezet zou kunnen worden om de beveiliging van Security-Enhanced Linux te omzeilen.

Spengler claimt dat hij de code heeft vrijgegeven nadat bleek dat Linus Torvalds en andere kernel-ontwikkelaars de kwetsbaarheid niet als een beveiligingsrisico beschouwden. "Toen ik de code schreef was er een fix beschikbaar, maar het zag er niet naar uit dat deze zijn weg zou vinden naar een stable release", vertelt Spengler tegen The Register. Inderdaad gaf Torvalds bij een discussie op een mailinglijst aan de exploit niet als een kernel-probleem te zien: "Hij draait een setuid-programma dat de gebruiker in staat stelt zijn eigen modules aan te wijzen en dan zijn jullie verbaasd dat hij local root krijgt?"

Marcus Meissner van Suse geeft wel toe dat er sprake is van een exploit die in theorie voor problemen kan zorgen, maar volgens hem zijn er twee aanvullende eisen waar een succesvolle aanval aan moet voldoen. De code moet namelijk in staat zijn om /dev/net/tun-apparaten te openen en om de mmap_min_addr-beveiliging uit te schakelen. Ook zou de oplossing eenvoudig zijn. In kernel 2.6.30.2 zou de bug dan ook al verholpen zijn.

Moderatie-faq Wijzig weergave

Reacties (81)

Vanochtend gelezen op webwereld en op Techworld

wat belangrijker is; de oplossing voor het probleem. Wat zijn 'onze jongens' toch snel :+
Reacties in de mailing list zijn wel triest leuk :X


diff --git a/drivers/net/tun.c b/drivers/net/tun.c

[Reactie gewijzigd door himlims_ op 20 juli 2009 16:56]

Lekkere code als ik dat zo zie. Als je dat soort dingen in userspace flikt heb je een segmentation fault om je oren.
Sjah, hoe dieper je gaat, hoe minder systemen/mechanismen die bugs in de code kunnen opvangen.
Ik dacht dat dit geen segfault op zou leveren, maar dat doet het dus inderdaad wel.

[Reactie gewijzigd door serkoon op 20 juli 2009 22:10]

Dat is dus precies waarom dit soort dingen niet als security bug worden gezien. Ja, natuurlijk, Open Source heeft "thousands eyes reading the code" maar die verwachten niet dat de kernel zomaar iets op NULL mmap()t. Je hebt daardoor geen processor trap, en Linux kan dus ook geen segfault genereren.
Linus mag zeggen wat hem wil, lijkt mij nogthans wel een bug.

[Reactie gewijzigd door flubug op 20 juli 2009 17:54]

Ach ja, hoe het beestje ook heet, hij is nu gesquasht. :P

offtopic:
Het is trouwens nochtans ;)
Het gaat er ook om hoe groot de exploit kans is op een gemiddeld systeem, en die is verwaarloosbaar klein (maw: een storm in een glas water)
Zijn 'ze' toch lkkr snel
Ja, zo kan ik ook "snel" zijn. De fix was er al eerder dan de code:
. "Toen ik de code schreef was er een fix beschikbaar, maar het zag er niet naar uit dat deze zijn weg zou vinden naar een stable release",
Maar eh, als er niets stuk is dan is er toch niets te fixen?
Dus blijkbaar ben jij het niet met Linus eens als je het een fix noemt? ;)
De kern van het probleem huist in een null pointer dereference, die te misbruiken is middels de optimalisatiefunctie van de GNU Compiler Collection.
Is dit een fout van de programmeur of van de compiler? Jammer dat hier niet op ingegaan wordt. :(
Het lijkt een onbedoeld bijeffect van een GCC optimalisatie te zijn. Volgens http://xorl.wordpress.com...null-pointer-dereference/ zit het hierin:

struct sock *sk = tun->sk; // initialize sk with tun->sk

if (!tun)
return POLLERR; // if tun is NULL return error

Die if statement wordt weggeoptimaliseerd en dan kun je schrijven naar 0x00000000.
Als tun == NULL crasht de code toch al op tun->sk?
Hier stond iets wat niet klopte. Ja, je prog crasht erop :)

[Reactie gewijzigd door serkoon op 20 juli 2009 22:09]

...maar niet in Kernel mode!

Dat maakt volgens mij deze bug nog erger, kennelijk is het gewoonte of zelfs stijl om alvast aan de pointers te gaan knoeien voordat je weet wat de waarde is.

Alleen als je heel strict design-by-contract hanteert (http://en.wikipedia.org/wiki/Design_by_contract) kan je echt besparen op pointer-checks zonder blind te varen op de compiler, maar in Kernel mode mag je best een beetje voorzichtiger zijn.
...maar niet in Kernel mode!
Dan nog is de check incorrect. Op adres 0 staat zeker geen geldige tun.
Dat is de andere helft van de security exploit: mmap()ing van een opzettelijk foute "tun" op NULL.
Ik gok dat Linux gewoon een oops geeft, maar andere kernels panicen op zulke dingen. Je krijgt dan net zo goed een page fault als in userland, maar in de kernel valt er weinig op te lossen meestal -> panic.
Een fout van de programmeur van de compiler ;)

Overigens snap ik niet waarom het kernel team zijn code wijzigt wegens een bug in GCC? Beter kan GNU de bug in GCC fixen en gaan ze kernel voortaan met een nieuwere GCC compilleren. Alluwel de (al-dan-niet) exploit nu wel sneller verholpen is.
Niet dus. In alles behalve Kernel-mode crasht je programma op de null dereference en is de check daarna dus onnodig. De compiler weet echter niet uit zichzelf dat jouw code voor de Kernel bedoeld is!

Overigens kan je dus in Kernel mode soms best een reden hebben on NULL (=0x0) te dereferencen, dat zal je de compiler ook moeten uitleggen!
Je kernel oopst of panict op NULL-pointer dereferences, tenzij natuurlijk iemand actief de bug probeert te exploiten en iets gemapt heeft (in userland, mind you) op adres 0x0.

De Linux-kernel probeert dat mappen dus te voorkomen, als preventieve maatregelen tegen dit soort exploits. Toch blijken er allerlei leuke manieren te zijn (geweest) om dergelijke mappings te kunnen maken.
De check daarna is ook in kernel mode overbodig. De check ervoor ontbreekt echter, en dat is in kernel mode net zo fout als in userspace mode.

De kernel mag best een reden hebben om NULL te dereferencen, maar dan hoor je de correcte magische woorden te gebruiken ;)

int* volatile p = NULL;
*p = 0; /* living dangerously */

"volatile" vertelt de compiler dat 'ie hier van af moet blijven. Het had ook redelijk gewerkt in de originele buggy code, als het daar opzet was geweest om NULL te dereferencen.
Als ik de reactie van Linus zo lees zit het probleem niet zozeer in de kernel, maar voor een groot deel in de gebruiker van het systeem zelf. Ik weet dat dit meestal het geval is, maar dit lijkt toch meer een kwestie van een onderzoeker die naam wil halen.
Linus zegt idnerdaad niet dat het geen probleem is, hij zegt enkel dat het geen kernel probleem is. in tegenstelling tot wat veel mensen denken onderhoud linux alleen de kernel (mee), niet de uiteindelijke distibuties.

Dit is dus een compiler + bepaalde module die het probleem hebben, en daar moet dan ook de patch vandaan komen.
Het gaat zelfs over een testomgeving dus niet eens over een normale huis-tuin-en-keuken-omgeving. Daar moet je dus bepaalde handelingen uitvoeren, waarvoor je dus op de PC zelf bezig moet zijn als ik dit verhaal goed interpreteer, waarna er dus sprake is van kwetsbaarheid.
Volgens mij is de kwetsbaarheid van ieder systeem groot als de hacker recht achter het systeem zit. Daar helpen firewalls e.d. echt niet meer aan. Dat is geeneens storm in een glas water maar eerder storm in een vingerhoedje met een bodempje water!
2.6.18, die alleen door Red Hat Enterprise Linux 5 voor testomgevingen gebruikt wordt.
Versie 2.6.18 is DE vaste kernel versie van alle versies van RHEL 5.
Het lijkt er echter op dat het lek mogelijk alleen zit in een nieuwe gebackpoorte subversie van deze kernel versie die alleen voor de RHEL 5.4 testversie werd gebruikt en niet in de prodcutionele RHEL 5 versies.

[Reactie gewijzigd door 80466 op 20 juli 2009 17:22]

kwetsbaarheid in de tun-interface in Linux kernel 2.6.30 en 2.6.18, die alleen door Red Hat Enterprise Linux 5 voor testomgevingen gebruikt wordt
Ik denk dat die niet naar de versie van de kernel verwijst, maar naar tun-interface. :)
Volgens kernel-co÷rdinator Linus Torvalds is er echter geen sprake van een exploit.

De exploit,....
Is het nu wel of geen exploit? Volgens tweakers blijkbaar wel.

[Reactie gewijzigd door twooggy op 20 juli 2009 20:18]

De nieuwsberichten vereenvoudigen het verhaal, waardoor het eigenlijk niet meer klopt. Spengler heeft een exploit vrijgegeven met daarin een flink stuk commentaar met het verhaal achter de exploit. Daarin legt hij uit dat hij de bug eerst heeft aangetoond met behulp van wat video's op YouTube (niet zelf gekeken, maar dat maak ik uit z'n tekst op).

Op basis van naar ik aanneem niet echt duidelijke filmpjes concludeerde Linus dat het ging om een userland-probleem. Dat klopt gedeeltelijk ook: Sprengler misbruikt een bug in pulseaudio om root te krijgen om vervolgens de kernelbug(s) te exploiten.

De exploit is te vinden op http://grsecurity.net/~spender/cheddar_bay.tgz voor hen die alles willen weten :)
Het grootste probleem lijkt mij dat er niemand verantwoordelijk is voor het geheel. Ieder stukje software is eigendom van een ander en je krijgt als het tegenzit een van-het-kastje-naar-de-muur-verhaal. Dat is een veel groter en veel fundamenteler probleem dat de Linux-gemeenschap zal moeten oplossen dan een onpractische exploit.
En jij denkt dat er bij MS of Apple wel verantwoordelijkheid wordt genomen??
Als er 1 land is waar delegeren ( afschuiven ) belangrijk is, zijn het de VS wel...

Ik vind het juist prettig te weten dat er echte nerds bezig zijn met mijn OS, klinkt misschien wat lulliger dan ik het bedoel. :+
*zucht*
...een kwetsbaarheid in de tun-interface in Linux kernel 2.6.30 en 2.6.18, die alleen door Red Hat Enterprise Linux 5 voor testomgevingen gebruikt wordt.
Dit laat alle andere Linux distro's buiten schot.

Er is geen sprake van een exploit. Een exploit is een stuk software of iets dergelijks dat gebruik maakt van een bug met als doel misbruik te maken van het systeem.

Er is een bug ontdekt - voor de officiŰle release van de kernel. Lijkt me helemaal dik voormekaar!

Versie 2.6.30.2 van de kernel is offic´eel beschikbaar. Probleem opgelost.
Toch wel interessant aangezien dit een van de eerste exploits is die ik ken als het om Linux gaat. Blijft een storm in een glas water, maar toch. Bovendien, Linus geeft aan dat de gebruiker vrij slecht bezig moet zijn met zijn eigen veiligheid, dit geldt voor ieder systeem natuurlijk. Het moet alleen niet al te makkelijk zijn de boel op die manier te omzeilen nee.

[Reactie gewijzigd door vgroenewold op 20 juli 2009 16:52]

Jij bent er duidelijk niet naar op zoek... er zijn meer dan genoeg exploits voor Linux (geweest), alleen de meesten halen het nieuws niet. Ik zoek ze trouwens ook niet op, maar heb er af en toe wel een voorbij zien komen.
Er zijn zat exploits voor Linux hoor, google maar eens
Gelukkig worden exploids (sneller) gepatched onder linux, google maar eens

[Reactie gewijzigd door himlims_ op 20 juli 2009 16:55]

Er zijn idd zat exploit . Maar in verhouding tot windows steld het niks voor :D

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True