Elke Unix-hardeningschecklijst leert het je eigenlijk wel: stop nooit de huidige werkdirectory in het executiepad van de root. En met een goede reden. Want als het systeem bij het uitvoeren van een commando altijd in de huidige werkdirectory kijkt, is de kans groot dat je tijdens het uitvoeren van een systeemcommando per abuis een programma met dezelfde naam start dat zich in de betreffende directory bevindt.
Voor Microsoft werd deze basis beveiligingsregel de afgelopen maand nog eens pijnlijk duidelijk. Niet in relatie tot het starten van uitvoerbare programmatuur zelf, maar wel in relatie tot programma-onderdelen. Het blijkt voor hackers mogelijk om middels standaard Windows functionaliteit tijdens het openen van een bestand zoals bijvoorbeeld een pdf of een Powerpoint presentatie een virus of een ander kwaadaardig programma op de computer van een niets vermoedende gebruiker te plaatsen.
Wat gebeurt er precies
Hackers plaatsen een kwaardig programma dat dezelfde naam heeft als een echt programmaonderdeel in de werkdirectory van een gebruiker. Als de gebruiker een applicatie start, start deze applicatie het kwaadaardige programma automatisch mee op, waardoor de gebruiker een virus of andere malware op zijn systeem krijgt.
Iets meer details
Op het moment dat je een Windows applicatie opstart, roept deze voor de verschillende programma-onderdelen tijdens het laden veelal verschillende bestanden aan. Veel van deze bestanden staan bekend als een 'dll-bestand'. Tijdens het programmeren kan de software ontwikkelaar deze dll-bestanden (programma-onderdelen) op verschillende manieren laden. De eenvoudigste manier is door het besturingsysteem (Windows) de opdracht te geven dit bestand zelf op de standaardlocaties op te zoeken. Deze standaard locaties zijn:
– De directory van waaruit de applicatie laadt
– De huidige werkdirectory (CWD)
– De 'system' directory
– De 16-bit 'system' directory
– De Windows directory
– De directories die in het executie pad van de gebruiker voorkomen
Doordat de huidige werkdirectory vooraf niet is te voorspellen, is deze een erg onzekere factor in het geheel. Microsoft is al een jaar of tien bekend met dit probleem (men noemt het zelf functionaliteit), maar heeft het (vermoedelijk vanwege de vele applicatieafhankelijkheden) nooit structureel opgelost. Wel is met ingang van Windows XP SP2 de voorkeursvolgorde van de bovenstaande directories aangepast, waardoor de impact van het probleem iets kleiner werd.
Toen zich enige tijd terug de kwetsbaarheid met het laden van shortcut-icoontjes voordeed, werden verschillende beveiligingsonderzoekers weer eens getriggerd om naar de oorzaak van deze problematiek te kijken. Door de vele (media) aandacht die er voor het probleem ontstond (waarmee de bij dit risico horende dreiging veranderde) moest Microsoft wel reageren. Inmiddels maken hackers actief gebruik van deze ontwerpfout.
Wat kunnen we hier tegen doen
Er komt voor dit probleem geen beveiligingsupdate!
Het is dus alleen op te lossen door Windows anders in te stellen. Hiervoor heeft Microsoft uitgebreide informatie beschikbaar gesteld.
Doordat de wijziging een grote impact op bestaande bedrijfsapplicaties kan hebben, is het belangrijk om de functioneel applicatiebeheerders (zoals altijd, maar in dit geval misschien een beetje extra) nauw te betrekken bij de noodzakelijke veranderingen. Microsoft geeft ons een aantal opties. De belangrijkste:
1. Verwijder de huidige werkdirectory volledig uit het standaard zoekpad van DLL bestanden.
Deze optie is het meest veilig, maar heeft ook de grootste impact op bedrijfsapplicaties. Dit veroorzaakt bijna gegarandeerd bij elk groot bedrijf productieverstoringen.
Instelling: CWDIllegalInDLLSearch = 0xffffffff
2. Sta het een applicatie niet toe om een dll bestand uit een WEBDAV directory te laden.
WEBDAV directories maken het mogelijk om door firewalls en proxies heen op internet directories te benaderen. Deze optie is (vanwege de internetkoppeling) voor hackers het eenvoudigst te misbruiken. Deze instelling zal vermoedelijk relatief weinig conflicten veroorzaken en neemt het grootste deel van de dreiging weg.
Instelling: CWDIllegalInDLLSearch = 1
(Indien er op de werkplek geen gebruik wordt gemaakt van WEBDAV is het ook mogelijk deze functionaliteit volledig uit te schakelen. Dit heeft in relatie tot dit risico hetzelfde effect.)
3. Sta het een applicatie niet toe om een DLL bestand uit een WEBDAV directorie of een netwerkshare te laden. Indien een applicatie direct van een share wordt gestart, worden DLL's wel geladen. Deze optie neemt zowel in relatie tot internet als het interne netwerk de belangrijkste risico's weg. Deze optie vereist iets meer testwerk dan de vorige, maar zal voor veel gebruikers vermoedelijk haalbaar zijn.
Instelling: CWDIllegalInDLLSearch = 2
Verder is het nog mogelijk om applicatiespecifieke instellingen door te voeren. Lees hierover meer op de website van Microsoft.
De fout is pas volledig weg te nemen als alle gebruikte applicaties op een veilige manier met 'DLL Pre-Loading' omgaan. De kans dat dit in grote bedrijven met alle applicaties lukt is erg klein. Als eindgebruiker van de applicatie ben je hiervoor immers afhankelijk van de de medewerking van applicatieleveranciers die over het algemeen niet op deze extra ontwikkelinspanning zitten te wachten. Omdat prioriteit over het algemeen afhankelijk is van het aantal vragen of supportcalls heb ik daarom op deze website een voorbeeldbrief geplaatst. Hopelijk maakt deze voorbeeld brief het voor veel lezers eenvoudiger om leveranciers aan te sporen om serieus met dit probleem aan de slag te gaan.
Gezien de grote risico's die deze kwetsbaarheid met zich meebrengt raad ik iedereen aan om de impact van deze fout zo snel mogelijk te laten evalueren door de werkplek en applicatiebeheerders. Op deze manier kunnen passende beschermingsmaatregelen worden geïntroduceerd voordat misbruik van deze kwetsbare functionaliteit een grote vlucht neemt.
Ik heb die voorliefde voor DLL’s nooit helemaal begrepen. Ik kan me voorstellen dat men in de tijd dat een hare schijf 700 gulden voor 40 heuse MB’s kostte spraarzaam met schijfruimte omging, maar in deze van terra- en pentabytes overladen era is dat toch eigenlijk niet meer een issue?
Ook het intern geheugen is niet langer een bottleneck met 3 GB intern als ‘standaard’. En hoeveel applicaties die nu DLL’s gebruiken wil je nou helemaal tegelijk in het geheugen hebben? 3, 4, 10?
De ideale software bevat slechts één executable en mogelijk wat databestanden. Nooit problemen met versies van DLL’s etc. Geen gemier met registry instellingen of registratie van DLL’s.
Wil je van de software af, dan wis je de bestanden en je hebt geen bitje systeemvervuiling meer. Installeren via een eenvoudige kopieerslag, desnoods via een simpele batchfile.
Soms verlang ik gewoon naar MS-DOS terug…
Het betreft tera- en petabytes (niet terra- en pentabytes ;)). Aan petabytes zijn de fabrikanten nog LANG niet toe – sterker nog: de grootste verkrijgbare harddisks zijn al tijden 2TB.
Er zijn NU al problemen onder Windows met de hoeveelheden intern geheugen. Ook die 3 of 4GB loopt vaak snel vol, vanwege geheugenlekken, inefficiënte programmacode en allerlei standaard ingebouwde toeters en bellen die zelden of nooit gebruikt worden.
Niet dat ik voor de mogelijkheid ben dat programma’s DLL’s doorelkaar en van elkaar kunnen gebruiken en dat er steeds nieuwe versies van komen – da’s gewoon wachten op problemen. Oude programma’s die ook de nieuwe DLL’s voorgeschoteld krijgen, kunnen er onbruikbaar door worden. Achteraf gezien zijn shared DLL’s in elk geval zeker niet slim geweest. Ook niet vanuit ’t oogpunt van veiligheid.
Het wisselen tussen applicaties neemt alleen maar toe – dus die 10 applicaties die tegelijk open staan: ja, dat komt overal voor. Op dit moment heb ik bijv. 7 applicaties open, naast allerlei software die op de achtergrond draait (zoals de virusscanner).
Je hoeft niet terug naar MSDOS – pak gewoon Ubuntu :). Dat scheelt geheid 99% veiligheidsproblemen.
We moeten onderscheid maken tussen managed dll’s en unmanaged dll’s. Het gaat hierover het vervangen van unmanaged dll’s (of niet gesignde managed dll’s) door een versie met net een andere werking. Geldt dit probleem ook voor signed managed dll’s?
DLL is een poging tot een ELF achtige opzet. .so (shared) objecten werken zeer efficient in andere omgevingen.
Bij Microsoft heb ik DLL nog echte ruimte besparingen zien maken en meer problemen zien opleveren dan voordelen.
@Technicus ook bij UNIX systemen speelt dat.
Immers ook Solaris kent een hoop library elende.
Waneer je zelf niet de boel kan linken (en vooral zonodig kan compileren hetgeen dus OSS inhoud) valt dat ook lastig te voorkomen.
Ik denk dat het DLL probleem bij MicroSoft vooral voortkomt uit gebrek aan organisatie (diskstruktuur)
Een ieder zelf voor zijn project eigen DLL’s op het systeem waardoor uiteindelijk volkomen voorbij gegaan wordt aan het concept ervan.
Ontopic, bugjes kunnen natuurlijk gewoon gefikst worden.
Zolang het MicroSoft spul betreft mag je dat eigenlijk ook wel van dit bedrijf verwachten.
@Pascal: Inderdaad kent het bij UNIX ook zijn problematiek, MAAR daar kent het zijn voordelen ook. Namelijk de ruimtebesparing.
@RJ Tuinman:
voor gewoon gebruik gaat dat misschien nog op, dat je “even” wat disk- of geheugen bijprikt in het geval van een tekort
In de embedded sector ligt dat wat lastiger; daar waar performance telt, en geheugendisk kostenposten zijn, wil je hier wel wat efficiënter mee om kunnen gaan.
Alle overbodige DLL’s zijn in principe kosten in dat geval, dus als je die niet nodig hebt, is dat alleen maar mooi