Sikker indlæsning af biblioteker for at forhindre, at DLL-preloading-angreb

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.

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");