Peter, dank voor het melden, maar dat is nog steeds dezelfde patch die afgelopen maandagavond laat al is gepubliceerd en dinsdagochtend door de Redactie is genoemd, zie http://www.security.nl/artikel/34244/1/Microsoft_waarschuwt_voor_omvangrijk_DLL-lek.html.

Kennelijk zag jij de feitelijke download links ook niet omdat je by default naar NL pagina's kijkt (en de NL variant van http://support.microsoft.com/kb/2264107 eerst incompleet was, kennelijk is die NL webpagina nu geupdate).

Ook Cyberpunk zag de verwijzingen naar de downloads gisteren niet, maar de losse download pagina's (waarvandaan je WindowsXP-KB2264107-x86-NLD.exe kon downloaden) waren er toen al wel (zie de discussie in http://www.security.nl/artikel/34244/1/Microsoft_waarschuwt_voor_omvangrijk_DLL-lek.html).

N.b. de patch zelf doet feitelijk niets - totdat je een registerwaarde "CWDIllegalInDllSearch" aanmaakt en daar een waarde ongelijk aan 0 aan toekent. Voor problemen met programma's die ontstaan indien je de veiligste waarde 0xFFFFFFFF gebruikt (essentieel om DLL-wormen op USB memory-sticks te voorkomen) zie http://www.security.nl/artikel/34260/1/Problemen_na_DLL-lek-patch_KB2264107_en_CWDIllegalInDllSearch%3DFFFFFFFF.html).

maak je zin eens af ;-)

bovendien, als de patch niets doet, wat heeft het dan voor toegevoegde waarde om deze te installeren indien je de aanpassing al in het register maakt. Of betekent het dat juist de patch ervoor zorgt dat je zonder (of iig minder) problemen de register entry aan kan maken?

Okay dan: (essentieel om DLL-wormen op USB memory-sticks te voorkomen) zie http://www.security.nl/artikel/34260/1/Problemen_na_DLL-lek-patch_KB2264107_en_CWDIllegalInDllSearch%3DFFFFFFFF.html.

Da's hetzelfde als er al stond, behalve dan dat er helemaal op het einde van de zin een afsluitende ronde haak te veel stond. Een mooie zin is het niet, maar het was laat...

Overigens heeft Peter V op 1 punt gelijk: ik noem KB2264107 steeds een "patch" maar dat is wellicht een onjuiste benaming: uitsluitend het installeren daarvan verhelpt het probleem niet en ten tweede is er geen sprake van een een buffer overflow o.i.d. in de betrokken bestanden die "gepatched" wordt.
Nee, zolang KB2264107 niet hebt gedraaid zal ntdll.dll niet zijn vervangen door een nieuwe versie, en alleen die nieuwe versie kijkt naar "CWDIllegalInDllSearch" in het register, en dat doet ie elke keer als je een programma start dat vervolgens 1 of meer DLL's probeert te laden zonder daarbij een volledig pad te specificeren.

Voorbeeld: Als je Solitaire start (C:\Windows\System32\sol.exe), zal deze "Cards.dll", met daarin bitmaps van speelkaarten, proberen te laden (dus niet expliciet "C:\Windows\System32\Cards.dll"). 1 van de taken van ntdll.dll is om in zo'n situatie Cards.dll te vinden op je systeem, volgens een vaststaand zoekpatroon.

Onder de volgende omstandigheden:
- ofwel KB2264107 is nog niet geinstalleerd
- ofwel KB2264107 is wel geinstalleerd maar de registervariabele "CWDIllegalInDllSearch" bestaat (nog) niet
- ofwel KB2264107 is wel geinstalleerd, de registervariabele "CWDIllegalInDllSearch" bestaat wel, maar heeft als waarde 0

Dan geldt de volgende zoekvolgorde voor DLL's, uit http://support.microsoft.com/?scid=kb%3Bnl%3B2264107 (door mij aangevuld met de paden die in default installaties gelden):Let op: update KB2264107 heeft uitsluitend effect op punt 5, en alleen als je (met de hand) de registerwaarde "CWDIllegalInDllSearch" aanmaakt en een waarde ongelijk 0 geeft.

De waardes 1 en 2 zijn door Microsoft in het leven geroepen omdat ze bij het testen natuurlijk al hadden ontdekt dat de waarde 0xFFFFFFFF allerlei problemen oplevert (schandalig dat ze trouwens niet zelf gewaarschuwd hebben dat Outlook niet meer werkt na deze update, zouden ze bij Microsoft zelf Thunderbird gebruiken of zo?).

Probleem is dat de waardes 1 en 2 geen bescherming bieden tegen bijv. een besmette USB stick of een door verschillende personen gebruikt werkstation waarbij een kwaadwillende gebruiker "iets achter laat" op een lokale drive voor andere gebruikers, denk daarbij bijv. aan de map All Users\Documents\ (die Explorer overigens meestal als "Shared Documents" laat zien).

In de volgende bijdrage werk ik het voorbeeld van Solitaire verder uit.

Als je C:\Windows\System32\sol.exe start heeft ntdll.dll (zowel de oude als nieuwe versie) natuurlijk geen probleem om cards.dll te vinden, want die staat in dezelfde map als sol.exe (dus zoekmethode 1 in bovenstaand lijstje).

Als je C:\Windows\System32\sol.exe naar bijv. C:\Temp\sol.exe kopieert en die opstart, werkt het ook omdat Cards.dll via methode 2 gevonden wordt.

Daarna heb ik cards.dll naar C:\Temp\ gekopieerd. Vervolgens heb ik cards.dll in C:\Windows\System32\ hernoemd in cards_saved.dll (daar moest ik XP voor in safe mode starten, anders wordt er direct weer een exemplaar van cards.dll hersteld door Windows). De situatie op m'n PC was daarmee als volgt:

C:\Temp\sol.exe
C:\Temp\cards.dll
C:\Windows\System32\sol.exe
C:\Windows\System32\cards_saved.dll

Als ik C:\Windows\System32\sol.exe opstart werkt dat niet, hij kan geen cards.dll meer vinden. Starten van C:\Temp\sol.exe werkt natuurlijk wel, want cards.dll staat in diezelfde map. Daarna heb ik cards.dll naar een submap met de naam "SUBMAP" verplaatst, en tevens, in C:\Temp\, een simpele snelkoppeling (shortcut) aangemaakt naar C:\Temp\sol.exe:

C:\Temp\sol.exe
C:\Temp\Shortcut to sol.exe.lnk
C:\Temp\SUBMAP\cards.dll
C:\Windows\System32\cards_saved.dll

Starten van zowel sol.exe als de shortcut geven een foutmelding. Dat er geen verschil tussen zit is logisch, als je een shortcut aanmaakt en de working directory niet wijzigt, is die working directory gelijk aan de map waar de executable staat (en dus maakt het niet uit wat je opstart).

Vervolgens heb ik in die shortcut als working directory C:\Temp\SUBMAP\ ingevuld. Als ik die gewijzigde shortcut start, hangt het van KB2264107 en de registerwaarde "CWDIllegalInDllSearch" af wat er gebeurt:

- KB2264107 niet geinstalleerd: Solitaire werkt gewoon (haalt cards.dll uit de working directory C:\Temp\SUBMAP\)

- KB2264107 wel geinstalleerd, en "CWDIllegalInDllSearch" heeft als waarde 0, 1, of 2: Solitaire werkt gewoon. N.b. de waardes 1 en 2 hebben alleen betrekking op WebDAV drives en netwerk shares, dus niet op lokale drives en memory sticks.

- KB2264107 wel geinstalleerd, en "CWDIllegalInDllSearch" heeft als waarde 0xFFFFFFFF: foutmelding, kan cards.dll niet vinden. De reden hiervoor is dat ntdll.dll met deze instelling niet meer in de current working directory naar DLL's zoekt!

Nou levert sol.exe natuurlijk geen gevaar op, maar programma's die naar niet meegeleverde (optionele) DLL's zoeken terwijl je met zo'n programma ook bestanden opent, vormen helaas wel een risico. Hoe zit dat dan precies?

Stel MS Word zoekt standaard naar een optionele, niet meegeleverde DLL, genaamd SuperMacros.dll (fictief voorbeeld!) en klaagt niet als hij die niet kan vinden (jij weet dus niet dat Word naar een DLL met die naam zoekt). Jij krijgt van een collega een USB memory stick met daarop een MS Word bestand, maar, zonder dat jullie dat weten, ook met SuperMacros.dll (met wormfunctie). Als jij vervolgens in Word voor File|Open kiest en naar de drive-letter van de USB-stick gaat, zal dat de "current working directory" worden van MS Word. Overigens zul je die DLL niet zien staan op die USB stick (immers, MS Word laat by default alleen .doc en .docx bestanden zien, en bovendien kan de dll "hidden" zijn). Als MS Word met het openen van een bestand ook op zoek gaat naar SuperMacros.dll, zal deze gevonden worden, en zal de code erin worden uitgevoerd.

Als je nog geen MS Word hebt draaien en met Windows verkenner de rootdirectory van de USB stick opent, zou het kunnen dat je zo'n DLL ziet (echter waarschijnlijk niet als dat bestand "hidden" is). Als je dan op een .doc file klikt, zal MS Word opstarten met die drive en rootdirectory als "current directory", en zal dan zeker in dezelfde map zoeken naar SuperMacros.dll. Alleen de waarde 0xFFFFFFFF voorkomt de beschreven scenario's!

Oké, dank voor de heldere en uitvoerige uitleg Bitwiper :-)

Outlook 2003 (11.8325.8324 SP3) werkt nog steeds prima hoor na deze hotfix (euh, "tool"). Ik denk dat ze bij Microsoft gewoon geen Outlook XP uit 2001 meer gebruiken. Kennelijk Bitwiper nog wel? ;-)

Bedankt voor je bijdrages hierover, erg verhelderend.

Als bij jou Outlook nog werkt dan vermoed ik dat je in elk geval geen CWDIllegalInDllSearch = 0xFFFFFFFF hebt ingeklopt, dit vanwege een bijdrage in http://isc.sans.edu/diary.html?storyid=9445:Just in case: uitsluitend KB2264107 installeren is totaal zinloos (d.w.z. zonder de registerwaarde CWDIllegalInDllSearch ongelijk 0 te maken). Dat is niet iets dat ik zelf verzin, lees http://support.microsoft.com/kb/2264107/en-us# (Engelstalig) of http://support.microsoft.com/kb/2264107/nl# (Nederlands).

Met CWDIllegalInDllSearch=1 ben je in elk geval beschermd tegen aanvallen via WebDAV, met 2 bij je zo te zien beschermd tegen aanvallen via WebDAV en netwerkdrives. Geen van beide waardes biedt bescherming tegen lokale drives waaronder USB memory sticks, CD's en DVD's. Op de notebook die ik van m'n werkgever heb staat nog Office XP (a.k.a. 2002). Die versie verschilt weinig van 2003 en wordt nog ondersteund door Microsoft. Graag gedaan!

Jawel. Ik heb de patch ook nog getest door een DLL van een programma te verplaatsen naar een andere directory en vanuit die directory het programma te starten (dos box). Met CWDIllegalInDllSearch = 0 geen probleem, met CWDIllegalInDllSearch = 0xFFFFFFFF werkt het niet meer. Outlook 2003 blijft gewoon werken.

Ik denk dat er een boel programma's zijn de DLLs laden via het PATH (=laatste optie) en dus kwetsbaar zijn omdat net daarvoor CWD gecheckt wordt. Met CWDIllegalInDllSearch = 0xFFFFFFFF blijven die applicaties gewoon werken (maar zijn niet meer kwetsbaar). Ik ben zelf nog geen programma tegen gekomen dat niet meer werkt na deze patch.

Dank voor jouw bijdrage! Kennelijk is niet elke Outlook 2003 hetzelfde. Denkbaar is dat de melder op sans.edu destijds een upgrade heeft uitgevoerd vanaf een oudere versie en jij niet, maar ik kan op geen van jullie beiden schijven kijken, dus geen idee.

Persoonlijk denk ik dat dat wel meevalt. Oudere applicaties gooiden vaak alle meegeleverde DLL's in C:\Windows\System32\ (daarbij niet zelden latere versies van Microsoft DLL's overschrijvend met oudere), en die System32 wordt eerder gecheckt dan %PATH%. Applicaties die het system path (of dat van de user) uitbreiden, doen dat vaak om ervoor te zorgen dat het starten van een .exe (of .bat) bestand vanaf de commandline werkt. Ik heb persoonlijk (in elk geval niet bewust) nog nooit een programma gezien dat %PATH% uitbreidde om DLL's te kunnen vinden.

Kwetsbare applicaties zijn vooral die apps die zoeken naar optionele en niet geinstalleerde DLL's. Bij het zoeken daarnaar kom je gegarandeerd langs CWD (en vervolgens langs %PATH% natuurlijk).

Nog een stuk opinie erachteraan: wat mij betreft stelt Microsoft nu meteen een nieuwe en verstandige specificatie op, onder vermelding van de toekomstige datum van invoering, waarin er door Windows helemaal niet meer naar applicatie-specifieke DLL's gezocht zal worden. Dat is zonde van de tijd van de gebruiker, het is en blijft gewoon een lastig te voorspellen security risico, en bovendien bestaat daarmee de kans dat je een DLL van een andere applicatie met toevallig dezelfde naam vindt. N.b.: als een app in een verkeerde DLL de benodigde functies op basis van hun nummer i.p.v. hun naam aanroept, zijn crashes bijna gegarandeerd, en dat op zich kan weer een security risico betekenen (als je bijv. een webbrowser onder bepaalde omstandigheden kan dwingen om een functie in een verkeerde DLL uit te voeren, is het niet ondenkbaar dat dit tot bijv. een exploitable buffer overflow kan leiden).

In C:\Windows\System32\ staan MS DLL's die elke applicatie nodig kan hebben, maar die kun je natuurlijk -systeemonafhankelijk- laden met %SYSTEM%\dllname.dll.

N.b. het toevoegen van applicatie-specifieke DLL's aan C:\Windows\System32\ zou een doodzonde moeten zijn (zie bovenstaande naamconflicten en security risico's). Zoeken in C:\Windows\ en C:\Windows\System\ is natuurlijk helemaal flauwekul. Kortom, schrappen die onzin!

Voor de programmeurs onder de lezers: bijv. in dotNet kun je met "Application.StartupPath" de map van het programma opvragen (Google naar Get Application Directory taal voor andere programeertalen). Zet DLL's in diezelfde map of in een vaste submap, of zet het benodigde pad naar jouw DLL's in het register. Beter (zeker bij portable apps) is het om het gebruik van applicatie-specifieke DLL's zoveel mogelijk te vermijden en zeker niet met andere apps (van jou of derden) te gaan sharen, dat leidt alleen maar tot verdere DLL-hell (zie http://en.wikipedia.org/wiki/DLL-hell). Hou verder de richtlijnen van Microsoft in de gaten, maar vertrouw niet de op de eerste de beste MS webpagina, soms raaskallen ze bij Microsoft ook maar wat.

Bijv. de auteur van de eerste versie van de webpage http://support.microsoft.com/kb/2264107/en-us# kende duidelijk het verschil niet tussen registry keys en values (keys staan links in regedit, kennen permissies en een datum/tijd van laatste wijziging, maar hebben -behalve een eventuele default string value die rechts wordt weergegeven- geen waardes; rechts staan "values", elk bestaande uit een "value-name" en "value-data" van een gespecificeerd type).

Ondertussen (Revision 3.0) zijn de meeste fouten in die 2264107 pagina verwijderd, maar op een paar plaatsen (tabellen) staat er nog steeds "No key or other values" terwijl met key duidelijk naar de value-name CWDIllegalInDllSearch wordt gerefereerd (ik heb die terminologie ook niet bedacht, maar die is nou eenmaal zo, hou je er dus aan).