Zwakte in geheugenbeheer Linux maakt root-toegang mogelijk

Een zwakte in het geheugenmanagement van Linux maakt het mogelijk om naar het geheugen van een ander proces te schrijven. Op deze wijze kan root-toegang worden verkregen. Een patch om het probleem te verhelpen is al ingediend.

Jason Donenfeld plaatste op zijn blog een uitgebreide beschrijving van de zwakte, inclusief voorbeeldcode waarmee root-toegang op een Linux-systeem verkregen kan worden. De zwakte is te vinden in de beveiliging van /proc/pid/mem, de interface waarmee naar procesgeheugen geschreven kan worden. De beveiliging die ervoor zorgt dat een proces alleen naar zijn eigen stukje geheugen kan schrijven, blijkt niet afdoende.

Donenfeld ontdekte een manier om die beveiliging te omzeilen waarna hij bij het geheugen dat aan een su-proces toebehoorde kon komen. Daarin injecteerde hij een stuk code waardoor hij met root-toegang een shell kon starten. De code die Donenfeld publiceerde is inclusief comments nog geen 200 regels lang en kan overweg met zowel 32- als 64-bits-systemen.

Volgens Donenfeld is de Linux-kernel vanaf 2.6.39 vatbaar voor de exploit. Enkele dagen geleden is al een patch die de exploit onmogelijk moet maken ingediend en goedgekeurd. Uit een korte test blijkt dat een volledig gepatchte versie van Ubuntu 11.10 in ieder geval vatbaar is voor de exploit. Ook sommige recente Android-telefoons zouden in theorie vatbaar zijn, omdat het mobiele besturingssysteem op Linux gebaseerd is.

Reacties (108)

[Jorik]

saurik heeft al een exploit voor de Galaxy Nexus geschreven.

[Camembert1633]

Deze exploit is dus geschikt voor de galaxy nexus en de transformer prime.

Maar kan deze exploit dan gebruikt worden voor elke android versie? Aangezien deze exploit er al veel langer in zit. Saurik heeft zelf waarschijnlijk een nexus en een prime.

[Eagle0]

In versie 3.3rc1 is het opgelost.
Versies 3.2.1 en 3.1.10 die nu op kernel.org staan lijken wel lek te zijn.

Nog even een link naar de commit:
https://github.com/mirror...7efd422a804dbb27977a3cccc

[FunFair]

Het is wel grappig, dat voor de Ubuntu users dit een ongewenste bug is.. en voor bijvoorbeeld Android users dit een leuke feature is, als de fabrikant root niet toestaat

[MartijnHavinga]

'k zou het een minder leuke "feature" vinden als ik een programma installeer dat alleen maar internet rechten nodig heeft vanuit de market, en dat ik er dan later achterkom dat hij mijn hele telefoon heeft leeggetrokken qua persoonlijke data, en ook nog eens een keylogger heeft geïnstalleerd...

[MadEgg]

True, maar als je hierdoor eenvoudig kan jailbreaken en jezelf op die manier permanent root toegang kan verschaffen is het wel een leuk bijgevolg.

[Dreamvoid]

Jij niet, maar iemand die zijn toestel wil jailbreaken/rooten heeft zulke exploits nodig.

[watercoolertje]

Daar heb je zeker een punt, elke hack die 'goedaardig' te gebruiken is is ook kwaadaardig te gebruiken...

Ik heb dan ook nooit begrpeen waarom niemand een kwaadaardig iets heeft geschreven voor iOS waar je bijv voorheen via de browser root kon verkrijgen!

[Verwijderd]

Daar heb je zeker een punt, elke hack die 'goedaardig' te gebruiken is is ook kwaadaardig te gebruiken...

Ik heb dan ook nooit begrpeen waarom niemand een kwaadaardig iets heeft geschreven voor iOS waar je bijv voorheen via de browser root kon verkrijgen!

Je weet niet of zoiets bestond. Als dat op kleine schaal werd gebruikt neem ik aan dat dit ongemerkt kan blijven. IOS heeft immers geen virusscan ofzo.

[Dreamvoid]

Of via een PDF?

[judgewooden]

Android is niet kwetsbaar, want die kernel is al geforked voor versie 2.6.39!

[Sir Guinhill]

De Kernel voor ICS op mijn Sensation is versie 3.0.16.
Ik neem aan dat deze versie een fork is die ook vanaf de main linux kernel is gemaakt. En niet een doorontwikkeling is van de 2.x kernel.

Dus voor ICS kan het best zijn dat dit een nieuwe optie is om root toegang te krijgen.

Ik vraag me alleen af hoe makkelijk deze "zwakte" van buiten af uit te buiten is.
Als je door een zwakte in een service ( zoals b.v. apache e.d. ) de account die deze service draait de code kan laten uitvoeren die SU toegang forceert... Dan is geen webserver meer veilig.

[iChaos]

3.0.16 is voor zover ik weet wel doorontwikkeld vanaf 2.X, want bij mijn weten is er dus toen de ontwikkeling bij 2.6.40 aankwam, deze gelijk omgedoopt naar 3.0.

[Trashed]

Klopt... de 3.x kernels hadden dus ook 2.6.x (of 2.7.x) kunnen heten. Bij mijn weten is de 3 geïntroduceerd om een nieuw decennium aan te duiden (de 2.x kernel ging alweer 10 jaar mee dus).

[arjankoole]

Als je door een zwakte in een service ( zoals b.v. apache e.d. ) de account die deze service draait de code kan laten uitvoeren die SU toegang forceert... Dan is geen webserver meer veilig.

Je bent sowieso vaak al het haasje als iemand zo binnen komt. Ik heb ook wel eens iemand binnen zien komen via een lek php script (vaak een groter risico dan een lek in apache), om vervolgens via een lek in se-linux (oh, the irony) root te worden. Dat koste aardig wat moeite om dat figuur weg te krijgen. (en uiteindelijk heeft die box een total whipe gekregen, ook al was ik er 99,9999% zeker van dat ie niet meer binnen kon komen via z'n backdoors, puur om het zekere voor het onzekere te nemen)

[IEF]

shell@android:/ $ uname -a
Linux localhost 2.6.39.4 #1 SMP PREEMPT Tue Jan 17 21:01:44 CST 2012 armv7l GNU/Linux
shell@android:/ $ /data/local/mempodroid
shell@android:/ # id
uid=0(root) gid=0(root)
shell@android:/ #

You were saying? (Transformer Prime)

Voor alle duidelijkheid, dit is een zgn. local root. Op android heb je dan ook in elk geval de 'shell' user nodig om root te kunnen worden, dus via 'adb shell', maw. met een usb kabeltje.
Autonoom (bijvoorbeeld via een Android App) kan dit dus niet.

[Reactie gewijzigd door IEF op 23 juli 2024 06:08]

[Aphax]

Uit nieuwsgierigheid, is het niet mogelijk dit vanuit een Android app met native code te doen?

Mijn TF101 heeft trouwens een oudere kernel (2.6.36), heb jjij 2.6.39 deze er zelf op gezet, of ben ik een update misgelopen?

[Reactie gewijzigd door Aphax op 23 juli 2024 06:08]

[midy922]

Transformer Prime mèt ICS heeft kernel 2.6.39.4.

[ritsjoena]

Android is niet kwetsbaar, want die kernel is al geforked voor versie 2.6.39!

Het kan zijn dat ze bij de ontwikkeling van Android nieuwere Linux code hebben overgenomen, danwel iets vergelijkbaars hebben gemaakt. Dit kan verklaren waarom er sommige staat en niet alle.

[ThomasG]

Dat betekend niet per definitie dat Android niet kwetsbaar is, hoewel het daarvoor al geforked is zou het best kunnen dat het een en ander is overgenomen, uit o.a. (beveiligings) updates waar de code die deze fout veroorzaakt tussen staat.

[dtech]

Android 4 is gebaseer op Linux kernel 3.0.1. De Android kernel wordt elke keer opnieuw gepatched voor Android, het is dus geen fork zoals jij impliceert.
Android is dus zeker wel vatbaar voor deze exploit.

[Verwijderd]

ieder OS is kwetsbaar als het interessant genoeg is om te exploten doet men heus wel genoeg moeite om dit te bewerkstelligen.

Om op internet te kunnen communiceren staan er poorten open, waar een open deur (poort) is daar is altijd een weg naar binnen te vinden.

Sinds Android veelvuldiger op mobiele telefoons gebruikt wordt en veel mensen daar nu hun bankzaken mee doen is het logisch dat Linux nu interessanter is en dus vaker onder de loep wordt genomen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:08]

[himlims_]

hahaha en alle reeds uitgegeven android telefoons draaien op die versie? en zijn eenvoudig te updaten naar die versie? ..... Nee!

[hostname]

Alle versies voor 2.6.39 zijn juist niet kwetsbaar...

[SirNobax]

Juist, vrijwel elk Android 2.3 of 3.1 toestel draait op Linux kernel 2.6.35 of 2.6.36.
Enkel ICS heeft een recentere kernel.

[Verwijderd]

Alle versies voor 2.6.39 zijn juist niet kwetsbaar...

thnx draai 2.6.38-8

[merethan]

himlims, nieuwere versie betekent niet perse veiliger of beter. Bugs worden niet alleen maar uitgeroeid, er worden ook nieuwe geïntroduceerd. In dit geval op 2.6.39. En de kernel van Android is geforked vanaf 2.6.30 ofzo.

[Eagle Creek]

Enkele dagen geleden is al een patch die de exploit onmogelijk moet maken ingediend en goedgekeurd. Uit een korte test blijkt dat een volledig gepatchte versie van Ubuntu 11.10 in ieder geval vatbaar is voor de exploit.

Ik vind bovenstaand stukje een beetje onduidelijk weergegeven.

Betekent dit dat de betreffende (ingediende en goedgekeurde) patch het probleem niet oplost (en nog steeds root-toegang mogelijk is), of bedoelt men met "een volledig gepatche versie van Ubuntu" een versie zonder bovengenoemde patch, maar wel met alle andere beschikbare patches (hence: je moet bovengenoemde patch alsnog installeren om het probleem te verhelpen)?

[Reactie gewijzigd door Eagle Creek op 23 juli 2024 06:08]

[MadEgg]

Ik denk dat deze specifieke patch nog niet uitgerold is op Ubuntu, maar wel is ingediend bij de kernel developers. Zal een kwestie van uren zijn voordat deze update via de diverse distro's wordt uitgerold denk ik, nadat het in de publiciteit is gekomen.

[Trashed]

Geen idee of dit inmiddels wél het geval is, maar ik krijg nu net de nieuwste update (inclusief kernel patch) binnen terwijl die pas is bijgewerkt. Wellicht vanaf nu dus wél uitgerold.

[hackerhater]

Update van vandaag
"Revert "proc: enable writing to /proc/pid/mem""

Jup dit is die

[MadEgg]

Check, net geupdate en de exploit werkt nu niet meer.

[Carharttguy]

De patch zal het probleem waarschijnlijk wel verholpen hebben, maar het duurd meestal nog even voor alle distributies de patch opnemen, en pushen naar de gebruikers. (kwestie van maximum enkele dagen (meestal uren))

[Reactie gewijzigd door Carharttguy op 23 juli 2024 06:08]

[Neko Koneko]

De patch is ingevoerd en goedgekeurd, maar dat betekent niet niet dat hij al is gepubliceerd bij de afzonderlijke distro's. Op dit moment is Ubuntu dus met alle patches die op dit moment beschikbaar zijn nog steeds kwetsbaar.

[Bjornski]

De patch is ingediend voor de Linux kernel. Ubuntu moet die eerst overnemen (of de hele kernel, of de patch). Hiermee toont men aan dat veel standaard distributies waarschijnlijk vatbaar zullen zijn.

[r03n_d]

Vraag me alleen af wat dit zou kunnen betekenen voor kwaadwillenden. Volgens mij zijn er nu een aantal nieuwe 'hacks' in de maak die gretig gebruik zullen maken van deze ontdekking.

[Carharttguy]

Als je nu nog maar begonnen bent met het maken van een hacktool, ben je al veel te laat, de patch is al ingediend, distributies zijn binnen enkele uren veilig.

[Dreamvoid]

Behalve alle routers, telefoons, servers, etc die niet of pas later hun kernel updaten. Er is geen manier om een update naar *alle* clients te forceren.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 06:08]

[The Zep Man]

Behalve alle routers, telefoons, servers, etc die niet of pas later hun kernel updaten. Er is geen manier om een update naar *alle* clients te forceren.

Er is nog steeds lokale (shell) toegang nodig voordat deze exploit uitgevoerd kan worden. Het lek lijkt ernstig, maar is vergelijkbaar met exploits in Windows waarvoor maandelijks security updates worden uitgebracht met een omschrijving van Microsoft die als volgt begint:

"A security issue has been identified that could allow an authenticated local attacker to compromise your system and gain control over it."

Het is niet alsof iemand op afstand zonder toegang tot het systeem plots wel toegang heeft en rootrechten kan opeisen. In één van de lagen in het complete spectrum van buitenwereld (anonieme/niet ingelogde gebruikers) tot volledige controle over het systeem zit nu een gat. Dit zorgt er niet voor dat de andere beveiligingslagen ook automatisch falen.

Kort samengevat: als niemand kan inloggen op je router, is er niets aan de hand. Als iemand met kwade bedoelingen wel kan inloggen heb je vaak al grotere problemen dan alleen deze exploit. Overigens hebben consumentenrouters en soortgelijke apparatuur vaak maar een enkel root gebruikersaccount en is dit verhaal sowieso niet van toepassing.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 06:08]

[watercoolertje]

Die groep is dan ook veel te gefragmenteerd (de rede waarom er vaak geen update voor komt is juist omdat er niet enorm veel gebruikers zijn), het kan inderdaad onveilig zijn maar de hacker heeft zo klein bereik en moet zo goed zoeken om de mensen te vinden dat het het vaak niet waard is, lang leve fragmentatie zeg ik dan maar

[Caelestis]

Is niet belangrijk.
Als het bedrijf niet snel is met het updaten van zijn producten om te pushen dan is de kans ENORM groot dat ze niet eens de juiste versie kernel gebruiken.

Alleen degene die bij blijven met updates en deze regelmatig laten bijwerken kunnen hier last van krijgen en zijn dan ook gelijk snel genoeg om het probleem uit de wereld te helpen.

[MadEgg]

Dat zal waarschijnlijk aardig meevallen, binnen korte tijd zullen patches over alle distros uitgerold worden die over het algemeen automatisch geinstalleerd zullen worden waardoor de systemen niet kwetsbaar meer zijn.

Ook zal bovengenoemde AppArmor e.d. op servers waarschjinlijk het gevolg hebben dat deze exploit alsnog niet gebruikt kan worden omdat deze nog extra beveiligingsrestricties oplegt aan waar geschreven kan worden bovenop de security features van de kernel zelf, die in dit geval dus duidelijk tekort schieten.

[Essox Lucius]

Naast dat er op de meeste Linux machines allerlei veiligheidsmaatregelen ingebouwd zijn (ASLR) en er op de machine waarschijnlijk ook wel AppArmor o.i.d. geïnstalleerd is, kan ik met zekerheid zeggen dat deze 'gevaarlijke bug' en een lek in de geheugen beheer 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 geen rootrechten.
Daarvoor moet je je ook weer in allerlei bochten wringen... dus dan moet je nog wat hacken.
Op veel linux machines hebben auto-parsers weinig kans en niet elk script laat zich pushen.

Dit is niet geldig voor alle Linux versies.

http://security-tracker.debian.org/tracker/CVE-2012-0056

en de patch is inmiddels vrijgegeven:

http://git.kernel.org/?p=...7efd422a804dbb27977a3cccc


author Linus Torvalds <[e-mail]>
Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
committer Linus Torvalds <[e-mail]>
Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the
other related files.

This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open. That
simplifies the code a lot, but does mean that if you hold the file
descriptor open over an execve(), you'll continue to read from the _old_
VM.

That is different from our previous behavior, but much simpler. If
somebody actually finds a load where this matters, we'll need to revert
this commit.

I suspect that nobody will ever notice - because the process mapping
addresses will also have changed as part of the execve. So you cannot
actually usefully access the fd across a VM change simply because all
the offsets for IO would have changed too.

Reported-by: Jüri Aedla <[e-mail]>
Cc: Al Viro <[e-mail]>
Signed-off-by: Linus Torvalds <[e-mail]>

[Reactie gewijzigd door Essox Lucius op 23 juli 2024 06:08]

[MadEgg]

-edit-
Ongewenst ? en waarom?

Waarschijnlijk door je formulering in je originele post, wat je nu weggeedit hebt... 'geloof mij nou maar' komt niet echt over als een solide argumentatie!

Ik denk dat je het lek iets te veel bagatelliseert; het is wel degelijk een vrij ernstig lek. Gelukkig zijn er in redelijk wat situaties aanvullende maatregelen getroffen waardoor het niet universeel toepasbaar is, maar wel jammer dat het gebeurt. Wel wederom snel gepatcht, maar we zijn niet anders gewend van de kernel developers.

[Dreamvoid]

Wel wederom snel gepatcht

2.6.39 is alweer acht maanden oud, dus niet zo heel erg snel.

[MadEgg]

Snel gepatcht nadat het lek bekend wordt natuurlijk. Dat de fout erin zit is jammer, maar zo lang het probleem niet bekend is kan het natuurlijk ook niet opgelost worden. Aan de andere kant, zolang het probleem niet bekend is kan het ook niet misbruikt worden.

[mjtdevries]

Zolang het probleem niet bekend is bij kwaadwillende kan het ook niet misbruikt worden.

Het punt is echter dat het probleem nu 8 maanden niet bekend was bij goedwillenden en we niet weten of kwaadwillende het wel wisten. Want die gaan dat niet aan de grote klok hangen.

[MadEgg]

Het risico is inderdaad aanwezig. Toch hebben kwaadwillenden de neiging om dan de code te misbruiken waardoor er in ieder geval aan het licht gekomen was dat er een nieuw soort hack in omloop was, en zodra er ergens een exemplaar van werkende code opgedoken was had iemand dat kunnen reverse engineeren om zo alsnog het probleem op te sporen.

Bovendien zie je bij Linux toch wel vaak dat het niet echt getarget wordt, juist omdat het ook vaak het OS of choice is van de hackers zelf.

[aTmosh]

In alle software die complex genoeg is zitten fouten, dat is een gegeven waar je mee moet leven.

Wat in deze eerder van belang is zijn de gevolgen in patchsnelheid vanwege filosofie/bedrijfsmodel. Voor Linux geldt "zo snel mogelijk" (doorgaans uren na bekendwording), voor Windows "Hoeveel geld kost de PR schade als we het tot/na dinsdag laten liggen?".

Helaas komt het geregeld voor dat Microsoft iets jaren laat liggen waar ze al van weten, danwel dat iemand die een fout in MS' software vindt genoodzaakt is deze bekend te maken omdat zij anders geen reden zien om deze te patchen.

[SED]

Dit is onzin. De patchsnelheid van Windoes ligt erg hoog maar ze moeten met veel meer zaken rekening houden. Commerciele motieven spelen daar ongetwijfeld een rol, maar meer de vraag of een snelle slecht geteste patch meer schade kan aanrichten dan kan oplossen en hoe dit te voorkomen.
Men laa thet ook niet uit PR oogpunt liggen maa rom de zaken voor pros hanteerbaar en testbaar te maken. Zo maar even een patch uitrollen op een server doe je niet in productie en daar zijn testprocedures voor. Toch al opvallend dat velen in de linuxcommunity enekel uren na het uitbregen deze patch ongetest lijken uit te rollen. dan zit er meestal geen commercieel gevolg aan lijkt me zo.

[aTmosh]

Dit is onzin:

FTFY

Ligt de patchsnelheid nu hoger of lager dan bij Linux? Je probeert het tegelijkertijd te doen voorkomen alsof de snelheid hoger ligt met waarom het beter is dat de snelheid lager ligt m.b.v. welklinkende vaagheden als "beter voor de pro's".

Het moge duidelijk zijn dat 1 patchdag per maand, met uitzonderlijke out of cycle patches niet sneller kan zijn dan een fix die binnen enkele uren klaarligt, en jawel, getest en in distributies is opgenomen. Een betere vraag zou zijn of het doeltreffender is om een constante stroom van snelle patches te hebben dan een regelmatige dump van veel patches ineens. In mijn ogen duidelijk het eerste, omdat je dan als beheerder zelf kan bepalen wat je ermee doet, b.v. cherrypicken wat voor jou interessant is, wachten op een service window etc.

En geloof me, ik ben een pro, met jarenlange ervaring in een gemengde Windows/Linux omgeving met honderden servers waar patches zeer snel worden uitgerold. Dat kan als je design goed is, m.n. redundantie op alle niveau's. Testen doe je in een identieke stagingomgeving en/of virtualisatie met testharnas, loadgeneratie etc. We hebben het hier over 8 cijferige bedragen met nette SLA's en boeteclausules.

Het is ook complete onzin dat Linux patches niet goed getest zouden worden door de programmeurs, ik heb dat op OS vlak helemaal niet meegemaakt, maar heb me wel doodgeërgerd aan Windows omdat het daarmee wel regelmatig misgaat en doorgaans niet zo eenvoudig teruggerold kan worden.

Ik vind het juist opvallend dat er zoveel M$ apologisten rondlopen hier die de gebruikelijke FUD en TCO PR als zoete koek slikken, zonder over de externalisaties na te denken.

[Stoney3K]

[...]


Waarschijnlijk door je formulering in je originele post, wat je nu weggeedit hebt... 'geloof mij nou maar' komt niet echt over als een solide argumentatie!

Bovendien klinkt het als een verhaal wat (naast het gezever over moderaties in je post) compleet kant noch wal raakt.

Dit gaat niet over toegang tot het kernel-geheugen, al dan niet via scripts of parsers, maar over een stuk code wat blijkbaar door een overflow lek is en dus code als root (buiten het stukje wat voor jou 'beschermd' als gebruiker is gereserveerd) uit kan voeren.

Wat je dan als root doet is weer een tweede: In de demonstratie die boven staat is het het uitvoeren van een shell, maar je kan natuurlijk veel vervelender dingen uithalen, want als root kom je OVERAL bij. Daar heb je dus geen USB, parsers of wat dan ook voor nodig, alleen een (userland) account op de machine die je wil aanvallen en een mogelijkheid om je eigen code uit te kunnen voeren: Iets wat één van de eigenschappen is van een multi-user OS zoals Linux.

[Verwijderd]

En er dan ook even vanuit gaand dat er geen mandatory access control zoals selinux draait. Want daarmee dam je zelfs de rechten van de root user in.

[Caelestis]

Het is niet zo dat je door een overflow automatisch root rechten krijgt het gaat erom dat je code kan injecteren in een proces welke met sudo is gestart en via dat sessie de rechten krijgt.
In telefoons gebruik je ziezo geen sudo om dingen uit te voeren dus ook al is het exploit aanwezig zijn andriod telefoon onkwetsbaar. Tevens is de vraag dan hoe vaak iemand nou werkelijk het sudo cmd aanroept in zijn linux omgeving?

Het is typisch zo'n geval van weet wat je doet en er kan je niks gebeuren maar als je overal op klikt dan vraag je erom en is geen enkel beveiliging goed genoeg anders dan je verbannen van het computer in zijn geheel.

[merodach]

Zojuist getest op Fedora 16. Deze is ook niet vatbaar.

[Suspicion]

Heb je dit met of zonder exec shield getest? (sysctl -q kernel.exec-shield)
Misschien is het daarom dat de exploit op sommige distributies niet werkt.
RHEL 6 is ook niet vatbaar trouwens omdat de kernel versie te laag is .

[RSpliet]

En toch komt er een patch uit. Mogelijk dat SELinux hier ingrijpt... of execshield zoals hierboven, of...

[MadEgg]

In de blogpost kan je lezen dat op Fedora /bin/su met position independent code gecompiled is, in tegenstelling tot veel andere distributies. Daarom werkt de code niet as is. Wel heeft dezelfde persoon een alternatief gepubliceerd die wel werkt met Fedora.

Wat er nodig is is een SUID binary die een na aanroep output geeft op stdout of stderr, en die, bij voorkeur, zonder position independent code is gecompileerd. Bij Fedora wordt /bin/gpasswd aangedragen waarvoor dit geldt, ook /bin/eject schijnt te werken. Het varieert dus een beetje per distro welke tool je kunt gebruiken, maar zodra er een SUID binary is die met position independent code is gecompiled kun je deze exploit na kleine aanpassingen gebruiken op een kwetsbare kernel.

[Cr4sH]

[ Upstream Kernel Changes ]

* Revert "proc: enable writing to /proc/pid/mem"
- LP: #919115
- CVE-2012-0056

-- Andy Whitcroft <[e-mail]> Fri, 20 Jan 2012 10:19:07 +0000

sudo apt-get update && sudo apt-get dist-upgrade

[Reactie gewijzigd door Cr4sH op 23 juli 2024 06:08]

[borft]

als je netjes op debian/stable zit heb je sowieso nergens last van.

[Kees]

Als je netjes Ubuntu 11.10 of 10.04 LTS draaide had je er wel last van, en na deze dist-upgrade dus niet meer. Als je debian stable draait had je er inderdaad geen last van, maar dan heb je wel weer andere problemen

[Verwijderd]

Ik denk dat dit in het bedrijfs leven niet voor veel problemen zal zorgen. 2.6.39 is wel redelijk recent voor "enterprise" use. RHEL 6 zit op 2.6.32 en RHEL 5 zit op 2.6.18 (CentOS uiteraard dito). Ik geloof niet dat het bewuste stuk wat het lek veroorzaakt is gebackport is naar een van deze distro's.

[Verwijderd]

Maar het is een lokale exploit, dus zo'n groot gevaar is er nou ook weer niet toch?

[Verwijderd]

Veel exploits zijn opzich zelf niet gevaarlijk maar worden heel gevaarlijk in combinatie met andere exploits. Lokale root exploit + Webserver exploit = Remote root exploit.