Hoofdcategorieën
Device Settings

Volledig gepatchte Linux-kernel blijkt vatbaar voor aanval

Door Olaf van Miltenburg, maandag 20 juli 2009 16:43, views: 16.822

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.

Volgende 17:18 HP koopt ontwikkelaar van zakelijke fileservingsoftware Ibrix
Vorige 16:17 Acer komt met goedkope Linux-notebook
Advertentie

Reacties

«  1  2  »


Maar wel een teken dat ook Linux niet perfect is, wat vaak wel gesuggereerd wordt, en dat er ook in Linux waarschijnlijk nog genoeg gaten zitten waarvan dit er één was.

Geen enkel OS is perfect, dus ook uiteraard Linux niet.

Maar de "gaten" worden steeds vaker "gaatjes", waarbij er dan vaak ook nog eens de nodige randvoorwaarden nodig zijn om het gaatje te misbruiken.

Voor zowel Windows, OS-X, Linux en hun belangrijkste applicaties valt op dat de exploits die het afgelopen jaar nog gemeld zijn niet echt van het soort zijn waar je heel erg zenuwachtig van word.

Dat was een jaar of 5 geleden toch wel heel anders.

[Reactie gewijzigd door mjtdevries op maandag 20 juli 2009 17:03]



Only two remote holes in the default install, in a heck of a long time!
0 = Perfect
only 2 = niet perfect

;-)

"Remote hole" is een security bug die remotely exploitable is. Als je de security bugs mee teld waarbij je een shell nodig hebt dan kom je op een hoger getal. En deze linux bug is zo'n bug waarbij je een shell nodig hebt.

note: een shell nodig hebben kan ook in houden via een andere bug van een ander stuk software naar de shell breken (bijvoorbeeld een bufferoverflow in apache misbruiken)


Tss, gebruikt ie een echte Unix, gaat ie een linux wereld er boven op gooien.
Volgens mij kan dat de security niet ten goede komen. Het scheelt wel dat geen hond dit gebruikt en er dus waarschijnlijk ook geen mensen in zitten te zoeken naar exploits.

Pffft, die bsd hippies ook altijd...
Kom maar weer terug zo gauw je wél een modern OS hebt om mee te patsen, ipv die oude meuk die qua features 10 jaar achter loopt...

Daarnaast zullen dit soort gesprekken ook wel eens bij Microsoft zo letterlijk zijn voorgevallen. Juist doordat Linux zo'n community heeft stelt het mensen in staat hierachter te komen.

En dit is niet slecht bedoelt naar microsoft, ik draai ook gewoon de Windows 7 beta. Openheid is toch wel een beetje wat Linux drijft naar mijn mening.

Ik gebruik het ook graag, als thuisservertje en bedrijfsmatig mail, web, ed. is het toch wel heilig

Ze zullen inderdaad zijn voorgevallen. Sinds de introductie van SDL (Security Development Lifecycle) binnen Microsoft komen deze klasse bugs echter niet ver. Dit zijn namelijk statisch te vinden bugs. Microsofts SDL tool werkt ongeveer zo als de GCC null pointer optimizer, alleen klaagt die tool in plaats van de check te verwijderen.

Als het non-triviale software is, is het per definitie imperfect. Er kunnen overal wel bugs in kruipen, ook in de gedeelten waar je geen vat op hebt, zoals bijvoorbeeld de compiler in dit geval, waar er een "verkeerde" optimalisatie is doorgevoerd.
Aard van 't beestje, zeg maar.

Maar wat voor FOSS in 't algemeen wel te zeggen is, is dat als er security bugs ontdekt worden, dat ze heel snel worden opgelost (typisch binnen enkele dagen). Dat is wel anders bij grote proprietaire softwareprojecten (Windows, Mac OS X zijn 2 hele prominente voorbeelden).

Er zit een verschil tussen snel een fix maken, en een officiele bugfix uitbrengen die op ontelbare configuraties getest is zodat een willekeurige gebruiker er vrij zeker van kan zijn dat de fix geen nieuwe problemen veroorzaakt.

Een fix voor Windows of Mac OS X testen zodat ie voldoet aan de compatibiliteits eisen doe je niet even in een uurtje. Ook niet in een dag.

Tuurlijk wel, Microsoft heeft gebouwen vol met testsystemen staan die automatisch enorm veel kunnen testen. En daarnaast hangt het ook van de fix af, maar voor de meeste software (kernel is uiteraard een uitzondering) zou een fix gelijk moeten zijn onafhankelijk van de configuratie.

Tuurlijk maar of ze het ook echt gebruiken (herinnert zich het terugtrekken van service pack 6 voor NT4).

dan moet je toch eens beter graven... zo slecht was sp6 niet... ;-)


( herindert zich sp2 die zo erg was dat bijna de gehele netwerkstack onbruikbaar werd. )

sp6 werd na een kleine patch als 6a nog best bruikbaar... sp2 werd door de meeste bedrijven niet gebruikt omdat deze meer problemen veroorzaakte dan oploste

doe je niet even in een uurtje. Ook niet in een dag.

Dus jij hebt liever dat je servers weken een risico lopen dan dat je het risico loopt met een kernel update je machine een keer niet doorstart? Dan is 15 minuten downtime dus erger dan een gehacked systeem.....
Daarnaast zijn de patches van Windows of Mac OS X niet zo heilig als je nu doet voorkomen. Daar gaat ook genoeg mis, ik denk zelfs dat dat vergelijkbaar is met elkaar. Het enige voordeel dat je bij Linux hebt met een kernel update dat je heel vlot weer terug bent bij je vorige versie.

* TheGhostInc vraagt zich zoiezo af of die extra tests veel uitmaken, een goede systeembeheerder test altijd het effect van zo'n patch, of die nu wel of niet weken is getest maakt niet.

15 minuten?

Het is een standaardoptie in grub om je kernel 1x test te draaien.
Dan is het dus zo dat je een reboot draait, komt ie niet binnen de gestelde tijd online (2 minuten oid) geef je 'm een reset op afstand (powerswitch) en grub start automatisch de oude kernel op.

Bij professionele server systemen duurt het laden van de bios soms al 2 minuten of langer... :(

Nou dan heeft apple juist weer het voordeel er mee want ze gebruiken minder hardware dus ook stuk makkelijker om te testen :)

en dan nog faalt het vaak genoeg, zoals het probleem met de update om SATA2 te ondersteunen, die niet werkt op harde schijven die daadwerkelijk SATA2 snelheden haalt

http://discussions.apple.com/thread.jspa?threadID=2054387

Dat ging dan ook alleen fout op niet-Apple hardware. Apple levert namelijk geen schijven die snel genoeg zijn om hier last van te hebben.

Hangt af van de omvang van de fout.

Een fout in een functie die kan worden opgelost zonder dat de datastructuur aangepast wordt Heeft Veel minder Impact dan een fout in de functionele integratie van het OS.

Zelfs van triviale software kun je niet aantonen of zeggen dat deze perfect is. In welke taal je je trivale hello world programma ook schrijft, er is een compiler nodig, en dat is een alles behalve triviaal stuksoftware waar ook regelmaitg fouten in ziten.

Zelf al zou het in assembler schrijven en een linker gebruiken dan nog weet kan je code veiligheidslekken hebben..

Als we dat allemaal perfect zouden maken, hebben we altijd nog te maken met hardware waar fouten insluipen, dan wel in het ontwikkel proces dan wel in het productie proces.

Overigens klinkt dit inderdaad wel als een storm in een glas water.

Maar wel een teken dat ook Linux niet perfect is, wat vaak wel gesuggereerd wordt, en dat er ook in Linux waarschijnlijk nog genoeg gaten zitten waarvan dit er één was.
Ik zie het eerder als iets positief. Er is een bug gevonden, hij is gedocumenteerd, opgelost en gereleased.

Dit is geen bug maar een compiler-aanname die niet correct is voor de kernel.
Specifiek:
er wordt een null pointer check gedaan NA een stukje code waarin de pointer gereferenced wordt. De compiler denkt dat die check weg kan maar weet niet dat de check ECHT nodig is ivm SMP.

edit: waarschijnlijk wordt er in de toekomst een vlag aangezet bij kernel compilatie die deze optimalisatie (weghalen overbodige null pointer checks) uitzet.

[Reactie gewijzigd door dangerous op maandag 20 juli 2009 19:11]


Het zijn eigenlijk een stuk of wat bugs waar Sprengler mee speelt:

1) Een bug in pulseaudio waardoor je eenvoudig root kunt krijgen. Root is nodig om de volgende bugs te exploiten:
2) Een bug waardoor je pages kunt laten mappen op adres 0x0, terwijl de kernel dat expres probeert te voorkomen.
3) Een klein bugje/stijlfoutje in de kernel waardoor een pointer gedereferenced kan worden voordat de pointer gecheckt wordt.
4) Een flinke bug in GCC in de code optimalisatie waardoor de werking van de gecompileerde code wijzigt.

Bug 1 is gewoon stom, bug 4 is wat mij betreft het interessantst. Beschouw de volgende code:
|-----------------------------------------------------------------------------------------------------------------|
struct bla *sk = tun->sk;

if (!tun) {
return(ERROR);
}
sk->iets = 0x42;
|-----------------------------------------------------------------------------------------------------------------|

GCC heeft, omdat bij de toewijzing van 'sk' al een dereference wordt gedaan van 'tun', de check if (!tun) eruit gegooid. Dat is simpelweg incorrect. In de gegenereerde assembly-code zou 'struct bla *sk = tun->sk' niks anders worden dan het verhogen van de pointer 'tun' met een offset binnen die struct voor 'sk'. Het is dus gewoon een optelsom van een pointer met een vast getal.

Het op die manier dereferencen zou dus helemaal geen invloed moeten hebben op hoe daarna omgegaan wordt met de 'tun'-pointer; sterker nog: waarschijnlijk wordt de 'struct bla *sk = tun->sk' pas in assembly uitgevoerd op het moment dat die sk daadwerkelijk gebruikt wordt, -na- de 'if (!tun)'-check dus. GCC zou dus ook met de poten van die 'if'-statement af moeten blijven.

Leuk he, compilers die je code vulnerable maken? :)

[Reactie gewijzigd door serkoon op maandag 20 juli 2009 19:50]


Als jij zulke code schrijft dan heb je toch iets niet helemaal begrepen... (voor het geval je niet weet wat dat is: jij doet een aanname over wat de compiler volgens jou zou moeten doen met de eerste dereference)

Dit stukje code is gewoon fout!

Edit: ik zie dat jij hier slechts overschrijft, de code blijft fout natuurlijk. Zou Linus nooit Lint oid. gebruiken?

[Reactie gewijzigd door mawashigeri op maandag 20 juli 2009 20:26]


De code zelf is inderdaad niet echt netjes, maar zolang het bij een declaratie blijft gaat er op zich niks stuk. Het feit dat het hier tot een security vulnerability heeft weten schoppen bewijst echter wel dat het fout is :)

Er zijn wel een aantal open source projecten die Coverity scans (static analysis) doen van hun code, waaronder FreeBSD. Coverity zelf scant ook op eigen intiatief heel wat af. Blijkbaar worden dit soort scans bij Linux in ieder geval niet structureel toegepast.

Maar het zijn niet zomaar declaraties, het is een dereferencing van een dynamisch object!

Het is altijd semantisch ambigu als je dynamische toekenningen doet in het declaratieve deel van het block. Je mag geen aannamen maken over de manier en/of volgorde waarin deze toekenningen worden gedaan.

De reactie van Torvalds valt dus onder de noemer arrogant of zelfs simpelweg dom. Ik snap dat het daadwerkelijk misbruiken van de gevolgen van zulke programmeerfouten zeer lastig is (in dat deel heeft Torvalds gelijk), maar de algehele codeerstijl die ik daar zie geeft niet veel vertrouwen in de rest van de kernel.

"Dynamische toekenningen in het declaratieve deel van het block"? Over welke programmeertaal heb jij het? Dit is de Linux kernel, geschreven in C met GCC idiomen. "Semantisch ambigu"? Dit zijn programmeertalen, met een behoorlijk stricte definitie.

De formele beschrijving van dit gedrag is "Undefined Behavior". De consequentie daarvan is dat het programma (de kernel) daarna niet meer aan enige C regel hoeft te voldoen. Hier heeft GCC die regel correct omgekeerd: checks die alleen uitgevoerd zouden worden na UB zijn overbodig.

|-----------------------------------------------------------------------------------------------------------------|
struct bla *sk = tun->sk;

if (!tun) {
return(ERROR);
}
sk->iets = 0x42;
|-----------------------------------------------------------------------------------------------------------------|

GCC heeft, omdat bij de toewijzing van 'sk' al een dereference wordt gedaan van 'tun', de check if (!tun) eruit gegooid. Dat is simpelweg incorrect. In de gegenereerde assembly-code zou 'struct bla *sk = tun->sk' niks anders worden dan het verhogen van de pointer 'tun' met een offset binnen die struct voor 'sk'. Het is dus gewoon een optelsom van een pointer met een vast getal.
Ahum! kuch kuch hoest
dat staat er dus niet.

wat staat er wel?
struct bla *sk = tun->sk;
==> sk is a pointer to a struct of type bla, and store in this pointer the value of:
dereference the pointer tun, and from the resulting type retrieve the value of sk
volgens mij kunnen je C skills nog wel wat opfrissers gebruiken. nog even niet voor NASA werken ;-)

Oeh, verrek, je hebt helemaal gelijk. De waarde van de pointer wordt natuurlijk ook nog geladen in 'sk'. Dus crasht een app wel meteen hierop als 'tun' NULL is.

Hm. Vreemd dat ik daar zo lang op misgetuurd heb :)

Behalve dat je dus geen crash hebt, omdat er vanwege een andere bug memory ge-mmap()ed is op NULL.

Als je het exploit, uiteraard.

Uiteraard is het grote basisconcept van de Linux kernel nog 1 van de weinige veelgebruikte manieren om een computer te besturen die in essentie veilig is. Doordat er nu door een extra aangehangen functionaliteit een gat is ontstaan veranderd dat niet en blijft Linux nogsteeds erg veilig.
Desalniettemin is het natuurlijk goed om altijd op je hoede te zijn voor dit soort foutjes

@HerrPino

Nog nooit heeft iemand gezegt dat linux perfect is. Maar wat wel perfect is en wederom blijkt uit dit nieuws is dat linux niks verbergt. Wordt er iets gevonden dan is het algemene informatie en je kan er gif op innemen dat het probleem direct door behoorlijk wat man opgepakt wordt om het te dichten.

Dat tegen over het concept van microsoft dat als er een lek gevonden wordt er niemand wat van zegt en af wacht tot iemand een virus of trojan ervoor schrijft. Vervolgens dichten ze het in een service pack en denk men goh wat een leuke verbetering terwijl je ondertussen al tijden bloot gesteld bent aan mogelijke aanvallen.

Het gaat om het concept "Voorkomen is beter dan genezen"

Precies dezelfde gedachte die ik had! Jammer dat je weggemod wordt, want eigenlijk heb je gewoon gelijk. Maar je hebt je username dan ook niet mee ;)
Ik zal ook wel weggemod worden maar moest toch even kwijt dat bij mij precies dezelfde gedachte opkwam.

Ik heb al ~8 jaar een server op Linux draaien en dat ding is nog nooit gehacked of welk probleem dan ook. Deze exploit zit nota bene maar in één OS. Ook nog eens een testversie, dus storm in een glas water.

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!

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 maandag 20 juli 2009 16:52]


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 maandag 20 juli 2009 16:55]


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

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.

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 maandag 20 juli 2009 16:56]


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? ;)

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 maandag 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 maandag 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)


Als je het al wist, waarom heb je dan geen nieuwstip ingestuurd?

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 hAl op maandag 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. :)

zolang alles door mensen gemaakt word is niet perfect xD


Je kunt door middel van het Feedback knopje rechtsboven aan het artikel dit soort dingen op het forum melden :)

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

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.

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

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.

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 maandag 20 juli 2009 20:18]

«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 17:18 HP koopt ontwikkelaar van zakelijke fileservingsoftware Ibrix
Vorige 16:17 Acer komt met goedkope Linux-notebook
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011