Aanmelden met Microsoft
Meld u aan of maak een account.
Hallo,
Selecteer een ander account.
U hebt meerdere accounts
Kies het account waarmee u zich wilt aanmelden.

Ondersteuning voor Windows Vista Service Pack 1 (SP1) eindigt op 12 juli 2011. Als u beveiligingsupdates voor Windows wilt blijven ontvangen, moet u Windows Vista uitvoeren met Service Pack 2 (SP2). Raadpleeg deze Microsoft-webpagina voor meer informatie: De ondersteuning loopt af voor sommige versies van Windows.

Wanneer in een toepassing een DLL (Dynamic Link Library) dynamisch wordt geladen zonder een volledig gekwalificeerd pad op te geven, probeert Windows het DLL-bestand te vinden door een goed gedefinieerde set met dll's te doorzoeken. Als een aanvaller de controle over een van de dll's krijgt, kan deze de toepassing dwingen een schadelijke kopie van het DLL-bestand te laden in plaats van het DLL-bestand dat hij verwachtte. Deze aanvallen worden 'DLL-aanvallen bij vooraf laden' genoemd en komen veel voor in alle besturingssystemen die ondersteuning bieden voor dynamisch laden van gedeelde DLL-bibliotheken. Het effect van dergelijke aanvallen kan zijn dat een aanvaller code kan uitvoeren in de context van de gebruiker die de toepassing uitvoert. Wanneer de toepassing wordt uitgevoerd als administrator, kan dit leiden tot een lokale hoogte van bevoegdheden. We weten over de vernieuwde interesse in deze aanvallen. Om het effect van dit probleem op onze gemeenschappelijke klanten te beperken, geven we dit document vrij aan de ontwikkelaars-community om ervoor te zorgen dat ze dit probleem kennen en over de benodigde hulpmiddelen beschikt om het probleem in hun toepassingen op te lossen.

Samenvatting

Beschrijving van DLL-aanvallen bij het vooraf laden

LoadLibrary-aanvallen

Wanneer in een toepassing een DLL dynamisch wordt geladen zonder een volledig gekwalificeerd pad op te geven, wordt geprobeerd dit DLL-bestand te vinden door lineair te zoeken in een goed gedefinieerde set dll-zoeksets, ook wel DLL-zoekorder genoemd. Als Windows de DLL in de DLL-zoekorder opzoekt, wordt deze DLL geladen. Als Windows de DLL echter niet vindt in een van de dll-zoekorders, mislukt de DLL-laadbewerking. Hier volgt de DLL-zoekvolgorde voor de functies LoadLibrary enLoadLibraryEx,die worden gebruikt om DLL's dynamisch te laden:

  1. De map waaruit de toepassing is geladen

  2. De systeemmap

  3. De 16-bits systeemmap

  4. De Windows-map

  5. De huidige werkmap (CWD)

  6. De directories die worden weergegeven in de PATH-omgevingsvariabele



Kijk eens naar het volgende scenario:


  • In een toepassing wordt een DLL geladen zonder een volledig gekwalificeerd pad op te geven dat hij verwacht te vinden in CWD van de toepassing.

  • De toepassing is volledig voorbereid op het verwerken van de zaak als het DLL-niet wordt gevonden.

  • De aanvaller weet deze informatie over de toepassing en beheert CWD.

  • De aanvaller kopieert zijn eigen speciaal gemaakte versie van de DLL in de CWD. Hiermee wordt ervan uitgenomen dat de aanvaller hiervoor toestemming heeft.

  • Windows doorzoekt de dll-zoekorder in de dll en zoekt de DLL in CWD van de toepassing.

In dit scenario wordt de speciaal gemaakte DLL uitgevoerd binnen de toepassing en krijgt de huidige gebruiker meer bevoegdheden.

Aanbeveling Om deze aanval te voorkomen, kunnen toepassingen de huidige adreslijst (CWD) verwijderen uit het DLL-zoekpad door de
SetDllDirectory-API aan te roepen met een lege tekenreeks
(""). Als een toepassing afhankelijk is van het laden van een DLL uit de huidige adreslijst, verkrijgt u de huidige werkmap en gebruikt u deze om een volledig gekwalificeerd pad van LoadLibrary door te geven.



We zijn er ook van op de hoogte dat sommige ontwikkelaars LoadLibrary gebruiken om te controleren of een specifieke DLL aanwezig is om te bepalen welke versie van Windows door de gebruiker wordt uitgevoerd. U moet zich ervan bewust zijn dat hierdoor de toepassing kwetsbaar kan worden. Als de beïnvloede bibliotheek daadwerkelijk niet bestaat in de Windows-release waar de toepassing op wordt uitgevoerd, kan een aanvaller een bibliotheek met diezelfde naam in CWD invoeren. Het wordt ten zeerste aangeraden deze techniek niet te gebruiken. Gebruik in plaats daarvan de aanbevolen technieken die worden beschreven in HET MSDN-artikel 'De systeemversie verkrijgen'.

Een toepassing die invoegtoepassing van derden laadt en die de invoegtoepassing niet kan dwingen om een gekwalificeerd pad te gebruiken voor de LoadLibrary-aanroepen, moet SetDllDirectory("") aanroepen om CWD te verwijderen en vervolgens SetDllDirectory("locatie van invoegtoepassing installeren") aanroepen om de directory voor de installatie van de invoegtoepassing toe te voegen aan het DLL-zoekpad.

SearchPath-aanvallen

Een soortgelijke aanval doet zich voor wanneer een toepassing de SearchPath-API gebruikt om een DLL te vinden en het pad dat door SearchPath wordt geretourneerd dynamisch laadt. Hieronder volgt de standaardzoekvolgorde voor de SearchPath-API:

  • De map waaruit de toepassing is geladen

  • De huidige werkmap (CWD)

  • De systeemmap

  • De 16-bits systeemmap

  • De Windows-map

  • De directories die worden weergegeven in de PATH-omgevingsvariabele

Dit patroon wordt niet aanbevolen, omdat dit niet veilig is. We raden de functie SearchPath niet aan als methode voor het zoeken naar een DLL-bestand als het beoogde gebruik van de uitvoer een aanroep is naar de functie LoadLibrary. Hierdoor kan het verkeerde DLL-bestand worden gevonden omdat de zoekorder van de zoekfunctie van SearchPath verschilt van de zoekorder die door de functie LoadLibrary wordt gebruikt. Als u een DLL-bestand moet zoeken en laden, gebruikt u de functie LoadLibrary.

ShellExecute en CreateProcess


Variaties op deze problemen kunnen ook voorkomen wanneer ontwikkelaars soortgelijke functies aanroepen, zoals ShellExecuteen CreateProcess,om externe uitvoerbare bestanden te laden. We raden ontwikkelaars aan voorzichtig te zijn bij het laden van binaire gegevens en het volledig gekwalificeerde pad op te geven. Dit zou minder complex moeten zijn wanneer u een binair getal laadt in plaats van een bibliotheek.

Aanbevolen stappen voor softwareontwikkelaars

Ontwikkelaars wordt aangeraden het volgende te doen:

  • Validate their applications for instances of nonsecure library loads (voorbeelden van elke worden verderm in dit artikel gegeven). Dit zijn onder meer de volgende:

    • Het gebruik van SearchPath om de locatie van een bibliotheek of onderdeel te identificeren.

    • Het gebruik van LoadLibrary om de versie van het besturingssysteem te identificeren.

  • Gebruik volledig gekwalificeerde paden voor alle aanroepen naar LoadLibrary, CreateProcess en ShellExecute waar mogelijk.

  • Implementeert oproepen naar SetDllDirectory met een lege tekenreeks ("") om de huidige werkmap te verwijderen uit de standaard DLL-zoekrichting waar dit vereist is. Let op: SetDllDirectory is van invloed op het hele proces. Daarom moet u dit één keer vroeg in de initialisatie van het proces doen, niet voor en na oproepen naar LoadLibrary. Omdat SetDllDirectory het hele proces beïnvloedt, kunnen meerdere threads die SetDllDirectory aanroepen met verschillende waarden, leiden tot ongedefinieerd gedrag. Als het proces is ontworpen om DLL's van derden te laden, moet u bovendien testen om te bepalen of het instellen van een instelling voor het hele proces incompatibiliteiten veroorzaakt. Een bekend probleem is dat wanneer een toepassing afhankelijk is van Visual Basic for Applications, een instelling voor het hele proces incompatibiliteit kan veroorzaken.

  • Gebruik de functie SetSearchPathModeom de veilige proceszoekmodus voor het proces in te schakelen. Hiermee verplaatst u de huidige werkmap naar de laatste plaats in de zoeklijst van SearchPath voor de levensduur van het proces.

  • Vermijd het gebruik van SearchPath om te controleren of er een DLL bestaat zonder een volledig gekwalificeerd pad op te geven, zelfs als de veilige zoekmodus is ingeschakeld, omdat dit nog steeds kan leiden tot DLL Preloading-aanvallen.

Richtlijnen voor het identificeren van niet-onveilige bibliotheekbelastingen

In broncode zijn de volgende voorbeelden voorbeelden van het niet-snijden van bibliotheken:

  • In het volgende codevoorbeeld zoekt de toepassing naar 'schannel.dll' op basis van het minst veilige zoekpad. Als een aanvaller een schannel.dll in CWD kan plaatsen, wordt deze nog geladen voordat de toepassing de Windows-adresvensters naar de juiste bibliotheek doorzoekt.

    DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
    HMODULE handle = LoadLibrary(result);
  • In het volgende codevoorbeeld probeert de toepassing de bibliotheek te laden vanuit de verschillende toepassings- en besturingssysteemlocaties die aan het begin van dit document worden beschreven voor de LoadLibrary()-oproep. Als er een risico bestaat dat het bestand niet aanwezig is, kan door de toepassing worden geprobeerd het bestand te laden vanuit de huidige werkmap. Dit scenario is iets minder gevaarlijke dan in het vorige voorbeeld. De toepassingsgebruiker kan er echter nog steeds mee te maken hebben als de omgeving niet volledig voorspelbaar is.

    HMODULE handle = LoadLibrary("schannel.dll");




Hier volgen voorbeelden van betere, veiligere laad van bibliotheken:

  • In het volgende codevoorbeeld wordt de bibliotheek rechtstreeks geladen met behulp van een volledig gekwalificeerd pad. Er is geen risico dat de aanvaller schadelijke code introduceert, tenzij hij al schrijfmachtigingen heeft voor de doelmap van de toepassing.

    HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");



    Opmerking Zie de volgende bronnen voor informatie over het bepalen van de systeemmap:

    GetSystemDirectory

    http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetKnownFolderPath

    http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

  • In het volgende codevoorbeeld wordt de huidige werkmap verwijderd uit het zoekpad voordat LoadLibrary wordt aanroepen. Dit verlaagt het risico aanzienlijk, omdat de aanvaller ofwel de toepassingsmap, de Windows-directory of mappen die zijn opgegeven in het pad van de gebruiker moet controleren om een DLL te gebruiken die vooraf wordt geladen.

    SetDllDirectory ("");
    HMODULE handle = LoadLibrary("schannel.dll");
  • Op alle systemen met de beveiligingsupdate 963027 (beschreven in MS09-014)zou CWD definitief worden verplaatst naar de laatste plaats in de zoekvolgorde. Latere aanroepen naar de functie SetSearchPathMode vanuit dat proces waarmee wordt geprobeerd de zoekmodus te wijzigen, mislukken.

    SetDllDirectory ("");
    HMODULE handle = LoadLibrary("schannel.dll");
  • In het volgende codevoorbeeld wordt de huidige werkmap verwijderd uit het zoekpad voordat LoadLibrary wordt aanroepen. Dit verlaagt het risico aanzienlijk, omdat de aanvaller ofwel de toepassingsmap, de windows-directory of mappen die zijn opgegeven in het pad van de gebruiker, moet controleren om een DLL te gebruiken die de aanval vooraf laadt.

    SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );
    HMODULE handle = LoadLibrary("schannel.dll");

Procesmonitor gebruiken om onveilige belastingen dynamisch te detecteren

Microsoft publiceert een hulpprogramma met de naam Procesmonitor. Met dit hulpprogramma kunnen ontwikkelaars en beheerders het gedrag van een actief proces nauwlettend bijhouden. Procesmonitor kan worden gebruikt om dynamisch te detecteren of een van uw toepassingen mogelijk kwetsbaar is voor dit soort problemen.

  • Ga naar de volgende Microsoft-webpagina om Procesmonitor te downloaden:

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

  • Start uw toepassing door CWD te gebruiken die is ingesteld op een specifieke adreslijst. Dubbelklik bijvoorbeeld op een bestand met een extensie waarvan de bestands handler aan uw toepassing is toegewezen.

  • Stel Procesmonitor in met de volgende filters:



    alternatieve tekst

  • Als er een kwetsbaar pad wordt getroffen, ziet u iets dat lijkt op het volgende: alternatieve tekstDe oproep naar de externe bestandsindeling om een DLL te laden geeft aan dat dit een kwetsbaar programma

    is.

Meer informatie

Ga voor meer informatie naar de volgende Microsoft-webpagina's:

Dynamic Link Library Search Order

http://msdn.microsoft.com/library/ms682586(VS.85).aspxMSDN-documentatie over de functie SearchPath

http://msdn.microsoft.com/library/aa365527(VS.85).aspxMSDN-documentatie over de functie LoadLibrary

http://msdn.microsoft.com/library/ms684175(VS.85).aspxMSDN-documentatie over de functie SetDllDirectory

http://msdn.microsoft.com/library/ms686203(VS.85).aspxMSDN-documentatie over de functie SetSearchPathMode

http://msdn.microsoft.com/library/dd266735(VS.85).aspxBlogbericht van David Le engineer, Principal Security Engineer met Microsoft Office

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxBlogbericht van AndrewS, MSRC Engineering-team op DLL-aanvallen voor vooraf laden

http://blogs.technet.com/b/srd/archive/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability.aspx

Aanvullende bronnen

Meer hulp nodig?

Meer opties?

Verken abonnementsvoordelen, blader door trainingscursussen, leer hoe u uw apparaat kunt beveiligen en meer.

Community's helpen u vragen te stellen en te beantwoorden, feedback te geven en te leren van experts met uitgebreide kennis.

Was deze informatie nuttig?

Hoe tevreden bent u met de taalkwaliteit?
Wat heeft uw ervaring beïnvloed?
Als u op Verzenden klikt, wordt uw feedback gebruikt om producten en services van Microsoft te verbeteren. Uw IT-beheerder kan deze gegevens verzamelen. Privacyverklaring.

Hartelijk dank voor uw feedback.

×