Linux kwetsbaar voor variant DLL-lek
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.
#!/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.
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.
http://en.wikipedia.org/wiki/LD_PRELOAD#Mac_OS_X
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?
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.
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.
"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?
Tim
Er zijn er vast nog meer maar ik heb geen zin om ze op te zoeken voor je.
Er zijn er vast nog meer maar ik heb geen zin om ze op te zoeken voor je.
Herstel: geen arbitraire libraries. Van http://linux.die.net/man/8/ld.so:
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.
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.
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
http://archives.neohapsis.com/archives/fulldisclosure/2009-11/0372.html
https://services.netscreen.com/restricted/sigupdates/nsm-updates/HTML/TELNET:EXPLOIT:LD-PRELOAD.html
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
