Log på med Microsoft
Log på, eller opret en konto.
Hej
Vælg en anden konto.
Du har flere konti
Vælg den konto, du vil logge på med.

Support til Windows Vista Service Pack 1 (SP1) slutter d. 12. juli 2011. Hvis du fortsat vil modtage sikkerhedsopdateringer til Windows, skal du kontrollere, at du kører Windows Vista med Service Pack 2 (SP2). Du kan finde flere oplysninger på denne Microsoft-webside: Understøttelsen af visse versioner af Windows stopper.

Når et program indlæser et DLL (Dynamic Link Library) dynamisk uden at angive en fuldt kvalificeret sti, forsøger Windows at finde DLL-filen ved at søge i et veldefineret sæt mapper. Hvis en hacker får kontrol over en af mapperne, kan de tvinge programmet til at indlæse en ondsindet kopi af DLL-filen i stedet for den DLL-fil, som den havde forventet. Disse angreb kaldes for "DLL-forudindlæsningsangreb" og er fælles for alle operativsystemer, der understøtter dynamisk indlæsning af delte DLL-biblioteker. Effekten af disse angreb kan være, at en hacker kan udføre kode i konteksten for den bruger, der kører programmet. Når programmet køres som administrator, kan det føre til en lokal udvidelse af rettigheder. Vi kender til den nye interesse for disse angreb. For at begrænse effekten, som dette problem har på vores fælles kunder, udgiver vi dette dokument til udviklerfællesskab for at sikre, at de kender til dette problem og har de nødvendige værktøjer til at løse problemet i deres programmer.

Oversigt

Beskrivelse af DLL-forudindlæsningsangreb

LoadLibrary-baserede angreb

Når et program indlæser en DLL-fil dynamisk uden at angive en fuldt kvalificeret sti, forsøger Windows at finde denne DLL-fil lineært ved at søge gennem et veldefineret sæt mapper, der kaldes DLL-søgerækkefølge. Hvis Windows finder DLL-filen i dll-søgerækkefølgen, indlæses den pågældende DLL-fil. Men hvis Windows ikke finder DLL-filen i nogen af mapperne i DLL-søgerækkefølgen, returneres en fejl ved indlæsningen af DLL. Følgende er DLL-søgerækkefølgen for funktionerne LoadLibraryog LoadLibraryEx,som bruges til dynamisk at indlæse DLL'er:

  1. Den mappe, som programmet indlæste fra

  2. Systemmappen

  3. 16-bit systemmappen

  4. Windows-mappen

  5. Den aktuelle arbejdsmappe (CWD)

  6. De mapper, der er angivet i PATH-miljøvariablen



Overvej følgende scenarie:


  • Et program indlæser en DLL-fil uden at angive en fuldt kvalificeret sti, som det forventer at finde i programmet CWD.

  • Programmet er fuldt forberedt til at håndtere sagen, når DLL-filen ikke findes.

  • Hackeren kender disse oplysninger om programmet og styrer CWD.

  • Hackeren kopierer sin egen specialdesignede version af DLL-filen i CWD. Dette forudsætter, at hackeren har tilladelse til at gøre dette.

  • Windows søger gennem mapperne i DLL-søgerækkefølgen og finder DLL-filen i CWD i programmet.

I dette scenarie kører den specialdesignede DLL-fil i programmet og får den aktuelle brugers rettigheder.

Anbefaling For at forhindre dette angreb kan programmer fjerne den aktuelle arbejdsmappe (CWD) fra DLL-søgestien ved at kalde
SetDllDirectory API ved hjælp af en tom
streng (""). Hvis et program afhænger af indlæsningen af en DLL-fil fra den aktuelle mappe, skal du hente den aktuelle arbejdsmappe og bruge den til at overføre i en fuldt kvalificeret sti af LoadLibrary.



Vi er også opmærksomme på, at nogle udviklere bruger LoadLibrary til at validere, om en bestemt DLL findes, for at afgøre, hvilken version af Windows der køres af brugeren. Du skal være opmærksom på, at dette kan gøre programmet sårbar. Hvis det pågældende bibliotek rent faktisk ikke findes i Windows-versionen, som programmet udføres på, kan en hacker introducere et bibliotek med det samme navn i CWD. Vi anbefaler på det kraftigste, at du ikke bruger denne metode. Brug i stedet de anbefalede teknikker, der er beskrevet i MSDN-artiklen "Henter systemversionen".

Et program, der indlæser tredjeparts-plug-ins, og som ikke kan tvinge plug-ins til at bruge en kvalificeret sti til sine LoadLibrary-opkald, skal kalde SetDllDirectory("") for at fjerne CWD og derefter ringe til SetDllDirectory("plug-in install location") for at tilføje plug-in'ens installationsmappe til DLL-søgestien.

SearchPath-baserede angreb

Der opstår et lignende angreb, når et program bruger SearchPath API til at finde en DLL-fil og dynamisk indlæse den sti, der returneres af SearchPath. Følgende er standardsøgningsrækkefølgen for SearchPath API:

  • Den mappe, som programmet indlæste fra

  • Den aktuelle arbejdsmappe (CWD)

  • Systemmappen

  • 16-bit systemmappen

  • Windows-mappen

  • De mapper, der er angivet i PATH-miljøvariablen

Vi anbefaler ikke dette mønster, da det ikke er sikkert. Vi anbefaler ikke funktionen SearchPath som en metode til at finde en .dll-fil, hvis den tilsigtede brug af outputtet er i et opkald til funktionen LoadLibrary. Dette kan medføre, at du finder den forkerte .dll-fil, fordi søgerækkefølgen for funktionen SearchPath er forskellig fra den søgerækkefølge, der bruges af funktionen LoadLibrary. Hvis du skal finde og indlæse en .dll-fil, skal du bruge funktionen LoadLibrary.

ShellExecute og CreateProcess


Variationer af disse problemer kan også findes, når udviklere kalder lignende funktioner som ShellExecuteog CreateProcessfor at indlæse eksterne eksekverbare programmer. Vi anbefaler, at udviklere skal være forsigtige, når de indlæser binære og angiver den fulde sti. Dette bør udgøre mindre kompleksitet, når du indlæser en binær i stedet for et bibliotek.

Anbefalede trin til softwareudviklere

Vi anbefaler, at udviklere gør følgende:

  • Valider deres programmer for forekomster af usikre biblioteksbelastninger (eksempler på hver af dem gives senere i denne artikel). Disse omfatter følgende:

    • Brug af SearchPath til at identificere placeringen af et bibliotek eller en komponent.

    • Brug af LoadLibrary til at identificere versionen af operativsystemet.

  • Brug fuldt kvalificerede stier for alle opkald til LoadLibrary, CreateProcess og ShellExecute, hvor du kan.

  • Implementer opkald til SetDllDirectory med en tom streng ("") for at fjerne den aktuelle arbejdsmappe fra standard-DLL-søgerækkefølgen, hvor den er påkrævet. Vær opmærksom på, at SetDllDirectory påvirker hele processen. Derfor skal du gøre dette en gang tidligt i processens initialisering, ikke før og efter opkald til LoadLibrary. Da SetDllDirectory påvirker hele processen, kan flere tråde, der kalder SetDllDirectory med forskellige værdier, medføre udefineret funktionsmåde. Hvis processen er udviklet til at indlæse tredjeparts-URL-adresser, skal der desuden udføres test for at afgøre, om det vil medføre kompatibilitetsforanstaltninger for hele processen. Et kendt problem er, at når et program afhænger af Visual Basic for Applications, kan en indstilling for hele processen medføre kompatibiliteter.

  • Brug funktionen SetSearchPathMode tilat aktivere søgetilstanden for sikker proces for processen. Dette flytter den aktuelle arbejdsmappe til det sidste sted på searchPath-søgelisten i processens levetid.

  • Undgå at bruge SearchPath til at kontrollere, om der findes en DLL-fil uden at angive en fuldt kvalificeret sti, også selvom sikker søgetilstand er aktiveret, da dette stadig kan føre til DLL-forindlæsningsangreb.

Vejledning til at identificere usikre biblioteksbelastninger

I kildekoden er følgende eksempler på usikre biblioteksbelastninger:

  • I følgende kodeeksem eksempel søger programmet efter "schannel.dll" ved hjælp af den mindst sikre søgesti. Hvis en hacker kan placere schannel.dll i CWD, indlæses den også, før programmet søger i Windows-mapperne efter det relevante bibliotek.

    DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
    HMODULE handle = LoadLibrary(result);
  • I følgende kodeeksem eksempel forsøger programmet at indlæse biblioteket fra de forskellige program- og operativsystemplaceringer, der er beskrevet i starten af dette dokument for LoadLibrary()-opkaldet. Hvis der er risiko for, at filen ikke er til stede, forsøger programmet muligvis at indlæse filen fra den aktuelle arbejdsmappe. Dette scenarie er lidt mindre farligt end det forrige eksempel. Programmet udsætter dog stadig programbrugeren for risiko, hvis miljøet ikke er fuldstændig forudsigeligt.

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




Følgende er eksempler på bedre og mere sikre biblioteksbelastninger:

  • I følgende kodeeksem eksempel indlæses biblioteket direkte ved hjælp af en fuldt kvalificeret sti. Der er ingen risiko for, at hackeren introducerer skadelig kode, medmindre han allerede har skrivetilladelser til programmets destinationsmappe.

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



    Note For information about how to determine the system directory, see the following resources:

    GetSystemDirectory

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

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

  • I følgende kodeeksem eksempel fjernes den aktuelle arbejdsmappe fra søgestien, før der ringes til LoadLibrary. Dette reducerer risikoen betydeligt, da hackeren skulle styre enten programmappen, Windows-mappen eller eventuelle mapper, der er angivet i brugerens sti for at kunne bruge en DLL-forudindlæsningsangreb.

    SetDllDirectory ("");
    HMODULE handle = LoadLibrary("schannel.dll");
  • På alle systemer, der har installeret sikkerhedsopdatering 963027 (beskrevet i MS09-014),flytter følgende kode permanent CWD til det sidste sted i søgerækkefølgen. Senere opkald til funktionen SetSearchPathMode inde fra denne proces, der forsøger at ændre søgetilstanden, mislykkes.

    SetDllDirectory ("");
    HMODULE handle = LoadLibrary("schannel.dll");
  • I følgende kodeeksem eksempel fjernes den aktuelle arbejdsmappe fra søgestien, før der ringes til LoadLibrary. Dette reducerer risikoen betydeligt, da hackeren skulle styre enten programmappen, windows-mappen eller eventuelle mapper, der er angivet i brugerens sti for at kunne bruge en DLL-forudindlæsningsangreb.

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

Brug af Procesovervågning til dynamisk at registrere usikre belastninger

Microsoft udgiver et værktøj, der hedder Procesovervågning. Dette værktøj gør det muligt for udviklere og administratorer at holde tæt styr på funktionsmåden i en løbende proces. Procesovervågning kan bruges dynamisk til at registrere, om et af dine programmer kan være sårbar over for denne type problem.

  • Hvis du vil downloade Procesovervågning, skal du besøge følgende Microsoft-webside:

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

  • Prøv at starte dit program ved hjælp af CWD, der er indstillet til en bestemt mappe. Dobbeltklik f.eks. på en fil med et filtypenavn, hvis filbehandler er tildelt til programmet.

  • Konfigurer Procesovervågning med følgende filtre:



    alternativ tekst

  • Hvis der rammes en sårbar sti, ser du noget, der ligner følgende: alternativ tekstOpkaldet til det eksterne filshare for at indlæse en DLL-fil indikerer, at dette er et

    sårbart program.

Flere oplysninger

Du kan finde flere oplysninger på følgende Microsoft-websider:

Søgerækkefølge for Dynamic Link-bibliotek

http://msdn.microsoft.com/da-dk/library/ms682586(VS.85).aspxMSDN-dokumentation til funktionen SearchPath

http://msdn.microsoft.com/da-dk/library/aa365527(VS.85).aspxMSDN-dokumentation på funktionen LoadLibrary

http://msdn.microsoft.com/da-dk/library/ms684175(VS.85).aspxMSDN-dokumentation på funktionen SetDllDirectory

http://msdn.microsoft.com/da-dk/library/ms686203(VS.85).aspxMSDN-dokumentation på funktionen SetSearchPathMode

http://msdn.microsoft.com/da-dk/library/dd266735(VS.85).aspxBlogindlæg af David Leblanc, Principal Security Engineer med Microsoft Office

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxBlogindlæg fra Andrew Andrews, MSRC Engineering-teamet om forhåndsindlæsning af DLL-angreb

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

Flere ressourcer

Har du brug for mere hjælp?

Udvid dine færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Deltag i Microsoft insiders

Var disse oplysninger nyttige?

Hvor tilfreds er du med kvaliteten af sproget?
Hvad påvirkede din oplevelse?

Tak for din feedback!

×