Volledig gepatchte Linux-kernel blijkt vatbaar voor aanval

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.

IT-banen

Reacties (81)

himlims_

Linux

20 juli 2009 16:51

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

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

[Reactie gewijzigd door himlims_ op 23 juli 2024 07:25]

_JGC_ @himlims_ • 20 juli 2009 17:10

Lekkere code als ik dat zo zie. Als je dat soort dingen in userspace flikt heb je een segmentation fault om je oren.

Ibex @_JGC_ • 20 juli 2009 17:39

Sjah, hoe dieper je gaat, hoe minder systemen/mechanismen die bugs in de code kunnen opvangen.

serkoon @_JGC_ • 20 juli 2009 19:54

Ik dacht dat dit geen segfault op zou leveren, maar dat doet het dus inderdaad wel.

[Reactie gewijzigd door serkoon op 23 juli 2024 07:25]

MSalters @_JGC_ • 20 juli 2009 23:05

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.

Verwijderd @himlims_ • 20 juli 2009 17:49

Linus mag zeggen wat hem wil, lijkt mij nogthans wel een bug.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:25]

Upquark @Verwijderd • 20 juli 2009 18:57

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

offtopic:
Het is trouwens nochtans

blouweKip @Upquark • 20 juli 2009 19:47

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)

mjtdevries @himlims_ • 20 juli 2009 16:58

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?

Olaf van der Spek 20 juli 2009 18:51

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.

Arnoud Engelfriet @Olaf van der Spek • 20 juli 2009 19:00

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.

Olaf van der Spek @Arnoud Engelfriet • 20 juli 2009 20:47

Als tun == NULL crasht de code toch al op tun->sk?

serkoon @Olaf van der Spek • 20 juli 2009 21:16

Hier stond iets wat niet klopte. Ja, je prog crasht erop

[Reactie gewijzigd door serkoon op 23 juli 2024 07:25]

mawashigeri @serkoon • 20 juli 2009 22:25

...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.

Olaf van der Spek @mawashigeri • 20 juli 2009 22:45

...maar niet in Kernel mode!

Dan nog is de check incorrect. Op adres 0 staat zeker geen geldige tun.

MSalters @Olaf van der Spek • 20 juli 2009 23:06

Dat is de andere helft van de security exploit: mmap()ing van een opzettelijk foute "tun" op NULL.

serkoon @mawashigeri • 20 juli 2009 22:28

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.

hostname @Olaf van der Spek • 20 juli 2009 20:48

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.

mawashigeri @hostname • 20 juli 2009 22:28

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!

serkoon @mawashigeri • 20 juli 2009 23:11

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.

MSalters @mawashigeri • 20 juli 2009 23:11

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.

Bram S 20 juli 2009 16:49

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.

leuk_he @Bram S • 20 juli 2009 17:21

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.

TheCapK @leuk_he • 20 juli 2009 19:09

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!

Verwijderd 20 juli 2009 17:20

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 Verwijderd op 23 juli 2024 07:25]

bavanandel @Verwijderd • 20 juli 2009 17:51

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.

twooggy 20 juli 2009 20:18

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 23 juli 2024 07:25]

serkoon 20 juli 2009 20:45

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

SirBlade 21 juli 2009 07:16

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.

neeroeter 21 juli 2009 07:53

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.

mrlammers 21 juli 2009 10:07

*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.

vgroenewold 20 juli 2009 16:51

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 23 juli 2024 07:25]

BRAINLESS01 @vgroenewold • 20 juli 2009 16:54

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.