image

Linux kwetsbaar voor variant DLL-lek

vrijdag 27 augustus 2010, 09:50 door Redactie, 20 reacties

Bepaalde Linux distributies zijn kwetsbaar voor een variant van het DLL-lek waar Windows nu mee te maken heeft. Dat zegt de Britse beveiligingsonderzoeker Tim Brown. Het probleem is zeer waarschijnlijk vorig jaar via een patch in Debian geïntroduceerd, maar ook Fedora en Ubuntu zouden kwetsbaar zijn. "De laatste paar dagen is er veel te doen over het feit dat Microsoft Insecure Library Loading op afstand het uitvoeren van kwaadaardige code mogelijk maakt en dat Linux nooit met zo'n probleem te maken zou kunnen krijgen", aldus Brown. "Ik weet niet zeker of ik het daarmee eens ben."

De onderzoeker bedacht een manier waarop Linux bij het openen van legitieme bestanden kwaadaardige libraries kan uitvoeren. Volgens verschillende mensen op de Full-disclosure mailinglist zou het probleem door een Debian patch zijn veroorzaakt. "Een Debian patch die een beveiligingslek introduceert? Wow, dat is nog nooit eerder voorgekomen...", stelt Chort. "Geen noodzaak voor patches, Debian is standaard onveilig", aldus Paul Szabo.

Distro
Tomas Hoger van het Fedora Security Response Team laat op de OSS Security mainling list weten dat ook Fedora kwetsbaar is. Wat betreft de patch die het probleem veroorzaakte, zou die niet in de huidige Debian stable 0.8.0-2 en testing/unstable 0.11.0-2+b1 packages aanwezig zijn, maar wel in verschillende Ubuntu versies. "Stable Debian bevat in plaats daarvan de cu-config patch die het zelfde probleem lijkt te introduceren en wordt ook gebruikt in sommige Fedora packages", aldus Hoger.

Impact
In sommige gevallen zou het probleem volgens Brown op afstand te misbruiken zijn. "Maar er is geen gelijke van UNC in Linux. Maar dat is iets dat de meeste grote distributies zouden moeten overwegen om te patchen." De onderzoeker stelt dat het voornamelijk afhankelijk is van welke packages iemand geïnstalleerd heeft. "Het is iets waar elke half-competente Linux coder een exploit voor kan maken."

Dave Aitel merkt op dat het probleem voor Linux niet zo omvangrijk als met Windows het geval is. "De Windows bug betreft een fout in de architectuur in de zin van dat het niet realistisch is op te lossen en ernstig kapot is. Een andere fout in de architectuur was het in de eerste plaats toestaan van WebDav UNC shares", aldus de CTO van Immunity. "Op dit gebied is geen enkel platform perfect, maar is Windows de minst perfecte van de twee."

Update 13:17
Tim Brown heeft inmiddels een update geplaatst waarin hij het één en ander verduidelijkt.

Reacties (20)
27-08-2010, 10:01 door Anoniem
Hmm... 'k ben benieuwd of Max os X ook kwetsbaar is.
27-08-2010, 10:01 door Anoniem
Uit http://www.nth-dimension.org.uk/blog.php?id=87:
Consider the following script:

#!/bin/sh
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib
app start

What happens if LD_LIBRARY_PATH isn't set? Well, in that case, the app binary path is executed with an LD_LIBRARY_PATH of :/path/to/app/lib. This may seem perfectly satisfactory, but here's the rub. When the Linux dynamic linker sees a path with an empty directory specification such as :/valid/path, /valid/path: or /valid::/path, it treats the empty specification as $PWD.
Dus alleen als er ergens in een script LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib oid wordt gebruikt is er een probleem. Poeh, hoe vaak is dat? En let op: dit probleem in Linux wordt in no time echt gefixed. En niet met een "tool" die potentieel een boel programma's stuk maakt.
27-08-2010, 10:25 door Mysterio
Er heeft nog niemand iets geroepen over in de zin van "Ha! Linux is ook kwetsbaar!" en meneer hierboven schiet al in de defensie.

Het is niet erg om een mooi product af te leveren wat je helpt met het doen van de dingen die je wilt doen met de computer, wat niet perfect is. Ik ben in mijn ondermaans bestaan nog nooit iets tegengekomen wat volmaakt of perfect was. Dus ik geloof best dat Linux NV. het binnen no-time echt gemaakt heeft zonder al die prachtige applicaties die je draait, te slopen, maar dat is in mijn ogen al net zo boeiend als dat Microsoft er maanden of jaren over doet.

Behalve wanneer het actief misbruikt wordt. Dan moeten ze gaan rennen.
27-08-2010, 10:31 door U4iA
Ach ja, zo zie je maar weer dat geen enkel besturingssysteem perfect en foutloos is...en dat systeem zal er ook nooit komen zolang het door mensen wordt gemaakt, want die is ook niet perfect.
27-08-2010, 10:31 door SirDice
Door Anoniem: Hmm... 'k ben benieuwd of Max os X ook kwetsbaar is.
Ga er maar vanuit. OS-X heeft ook een soort LD_PRELOAD alleen heet het anders en werkt het ietsjes anders. Het effect blijft hetzelfde.

http://en.wikipedia.org/wiki/LD_PRELOAD#Mac_OS_X
27-08-2010, 10:32 door SirDice
Door Anoniem: Dus alleen als er ergens in een script LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib oid wordt gebruikt is er een probleem. Poeh, hoe vaak is dat? En let op: dit probleem in Linux wordt in no time echt gefixed. En niet met een "tool" die potentieel een boel programma's stuk maakt.
Jij begrijpt duidelijk niet hoe LD_PRELOAD werkt.
27-08-2010, 10:56 door Anoniem
LD_LIBRARY_PATH... Dat is zonder meer een slechte manier van libs laden.
Verschillende audittools ( Lynis en Rootkithunter controleren hier onder andere op ).

Over LD_PRELOAD kon ik dit vinde:
"There is a shell environment variable, LD_PRELOAD, which will allow arbitrary shared libraries to be loaded prior to running any program. These shared libraries can override functions in glibc, or other libraries, and do other things, including calling the original library function."

Leuk voor debugging, niet voor een systeem dat veilig moet zijn.
Ik neem aan dat dit alleen werkt als root?
27-08-2010, 11:04 door Anoniem
SirDice, dit heeft niks met LD_PRELOAD te maken.

Het punt was dat als in LD_LIBRARY_PATH een lege directory staat, dus bijv 'LD_LIBRARY_PATH=:/usr/local/lib', die lege directory ervoor zorgt dat de CWD wordt gebruikt om libraries te zoeken. Dat komt dus gewoon vrijwel niet voor, zoals Anoniem@10:10 terecht opmerkt.

Bovendien is er helemaal geen manier om dit remote te doen, waardoor dit nog meer een non-issue is.
27-08-2010, 11:10 door Anoniem
Door SirDice: Jij begrijpt duidelijk niet hoe LD_PRELOAD werkt.
Jawel. Iedereen kan LD_LIBRARY_PATH gebruiken en in een script zetten. Maar dat is geen aanvalsvector: dan ben je jezelf aan het exploiten. Om de vergelijking met de Windows bug te kunnen maken moet je:

1) Een handler hebben die een programma opent als je op een bestand klikt
2) Deze handler moet een script zijn waarin LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/app/lib gebruikt wordt
3) $LD_LIBRARY_PATH moet initieel leeg zijn
4) Het bestand moet op een plek staan waar een aanvaller een kwaadaardig shared object (.so) neer kan zetten, bijvoorbeeld een WebDAV web folder

Ik heb nog niet gehoord dat punt 2 ergens standaard is in een Linux distributie. En volgens mij is punt 3 ook al niet standaard in Linux: je kan niet zomaar iemand een remote share/web folder/mount point laten gebruiken. Dit kan in Windows wel en dat maakt het DLL search path probleem (dat al 10 jaar bekend is) nu zo gevaarlijk. IMHO is dit LD_LIBRARY_PATH verhaal wel een security issue in Linux, maar de impact is bij lange na niet zo groot als in Windows.
27-08-2010, 11:35 door SirDice
Door Anoniem:
Door SirDice: Jij begrijpt duidelijk niet hoe LD_PRELOAD werkt.
Jawel. Iedereen kan LD_LIBRARY_PATH gebruiken en in een script zetten. Maar dat is geen aanvalsvector: dan ben je jezelf aan het exploiten.
Wederom iemand met een gebrek aan fantasie. Het is op zeker een aanvalsvector. Bedenk dat een aanvaller middels LD_PRELOAD een 'vertrouwd' programma ook andere dingen kan laten doen. Om nog maar even te zwijgen over eventuele verhoging van privileges. Bedenk namelijk wat er kan gebeuren indien je LD_PRELOAD zou gebruiken voordat je een suid root programma start. Sudo bijv. filtert niet voor niets LD_PRELOAD.
27-08-2010, 11:42 door SirDice
Door Anoniem: Over LD_PRELOAD kon ik dit vinde:
"There is a shell environment variable, LD_PRELOAD, which will allow arbitrary shared libraries to be loaded prior to running any program. These shared libraries can override functions in glibc, or other libraries, and do other things, including calling the original library function."

Leuk voor debugging, niet voor een systeem dat veilig moet zijn.
Ik neem aan dat dit alleen werkt als root?
Nee, het werkt voor elke gebruiker.
27-08-2010, 11:47 door Anoniem
Door SirDice: Wederom iemand met een gebrek aan fantasie. Het is op zeker een aanvalsvector. Bedenk dat een aanvaller middels LD_PRELOAD een 'vertrouwd' programma ook andere dingen kan laten doen. Om nog maar even te zwijgen over eventuele verhoging van privileges.
Sorry dat ik zo fantasieloos ben. Werk eens een aanvalsvector uit? Ik zie het nog steeds niet.

Bedenk namelijk wat er kan gebeuren indien je LD_PRELOAD zou gebruiken voordat je een suid root programma start. Sudo bijv. filtert niet voor niets LD_PRELOAD.
Je moet toch wat vaker Linux gebruiken. Suid programma's laden geen libraries via LD_LIBRARY_PATH / LD_PRELOAD. Dat zou een ernstig security issue zijn.
27-08-2010, 13:06 door Anoniem
Hi, I don't speak Dutch but I have written a comment on the Threatpost article (http://threatpost.com/en_us/blogs/some-linux-distros-vulnerable-version-dll-hijacking-bug-082610) which should clarify the points I'm trying to make and some of the misunderstandings you guys may have.

Tim
27-08-2010, 13:47 door SirDice
Door Anoniem: Sorry dat ik zo fantasieloos ben. Werk eens een aanvalsvector uit? Ik zie het nog steeds niet.
Exploit die gebruik maakt van LD_PRELOAD: http://www.0xdeadbeef.info/exploits/raptor_libnspr2
Er zijn er vast nog meer maar ik heb geen zin om ze op te zoeken voor je.

Bedenk namelijk wat er kan gebeuren indien je LD_PRELOAD zou gebruiken voordat je een suid root programma start. Sudo bijv. filtert niet voor niets LD_PRELOAD.
Je moet toch wat vaker Linux gebruiken. Suid programma's laden geen libraries via LD_LIBRARY_PATH / LD_PRELOAD. Dat zou een ernstig security issue zijn.
Nee, Suid programma's zouden geen libraries moeten laden via LD_PRELOAD. Dit wordt echter nergens afgedwongen en de enige bescherming zit in die suid applicatie. De programmeur moet hier specifieke handelingen voor uitvoeren om niet vatbaar te zijn. Niet elke programmeur is hier echter van op de hoogte en creert op die manier inderdaad een security risico.
27-08-2010, 14:32 door Anoniem
Door SirDice: Exploit die gebruik maakt van LD_PRELOAD: http://www.0xdeadbeef.info/exploits/raptor_libnspr2
Er zijn er vast nog meer maar ik heb geen zin om ze op te zoeken voor je.
In die exploit wordt via NSPR_LOG_FILE een nieuwe bestand /usr/lib/secure/getuid.so gemaakt dat schrijfbaar is voor iedereen. Dat wordt vervolgens gebruikt via LD_PRELOAD. De kwetsbaarheid is dus niet hoe LD_PRELOAD werkt, maar libnspr2 in dit geval. Dat arbitraire bestandscreatie leidt tot privilege escalation weet iedereen. Dat kan ook zonder LD_PRELOAD (overschrijf /etc/passwd oid).

Nee, Suid programma's zouden geen libraries moeten laden via LD_PRELOAD. Dit wordt echter nergens afgedwongen en de enige bescherming zit in die suid applicatie.

Herstel: geen arbitraire libraries. Van http://linux.die.net/man/8/ld.so:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set-user-ID will be loaded.

Wellicht dat LD_LIBRARY_PATH wel werkt voor suid, maar dan alleen als de standaard systeem directories de libraries niet bevatten. Dat zou een hele vreemde situatie zijn.
27-08-2010, 15:36 door SirDice
Door Anoniem: Herstel: geen arbitraire libraries. Van http://linux.die.net/man/8/ld.so:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF shared libraries to be loaded before all others. This can be used to selectively override functions in other shared libraries. For set-user-ID/set-group-ID ELF binaries, only libraries in the standard search directories that are also set-user-ID will be loaded.
Je hebt helemaal gelijk. Ik zit met oude informatie in m'n hoofd.

Al blijft dan nog de mogelijk over van een bug in de dynamic link loader zoals wel eens bij FreeBSD is gebeurd:
http://archives.neohapsis.com/archives/fulldisclosure/2009-11/0372.html

Overigens is LD_PRELOAD soms ook best remote te gebruiken:
https://services.netscreen.com/restricted/sigupdates/nsm-updates/HTML/TELNET:EXPLOIT:LD-PRELOAD.html
27-08-2010, 15:52 door Anoniem
En veilig is de X server dan? (ook suid)
27-08-2010, 16:34 door Anoniem
Door SirDice: Je hebt helemaal gelijk. Ik zit met oude informatie in m'n hoofd.
Geen probleem, kan gebeuren.
Al blijft dan nog de mogelijk over van een bug in de dynamic link loader zoals wel eens bij FreeBSD is gebeurd:
http://archives.neohapsis.com/archives/fulldisclosure/2009-11/0372.html
Dat was een vette bug in de rtld van FreeBSD, geen issue met het LD_PRELOAD mechanisme zelf.

Alleen als er een hele vette bug zit in een daemon zoals telnetd in dit geval. Uit die URL:
Attackers can place a shared object library containing executable code on the system, set this library as a LD_PRELOAD environment variable, and open a TELNET connection with the target host.
Dus je moet eerst een library op de host plaatsen. Dan kan best lastig zijn (hoeft niet).

Er kan best misbruik gemaakt worden van LD_PRELOAD / LD_LIBRARY_PATH maar alleen als er bugs zitten in de implementatie of een ander stuk software. Het Windows DLL search path probleem is een "feature" en wordt niet door Microsoft onderkend als bug. Klein verschil.
28-08-2010, 09:45 door soeperees
This vulnerability is only
triggered when the /usr/bin/couchdb script is executed explicitly,
since the init script (/etc/init.d/couchdb) changes the current
directory before launching CouchDB.

Nuf said.
29-05-2011, 00:25 door Anoniem
' "Geen noodzaak voor patches, Debian is standaard onveilig", aldus Paul Szabo. '

Wat een hufter is Paul. Vast en zeker een politieke medewerker van M$
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.