Sikker innlasting av biblioteker for å hindre at DLL-forhåndslastingsangrep

LoadLibrary-baserte angrep

Når et program laster en DLL-fil dynamisk uten å angi en fullstendig bane, prøver Windows å finne denne DLLen lineært ved å søke gjennom et veldefinert sett med kataloger, kalt DLL Search Order. Hvis Windows finner DLL-en i søkerekkefølgen for DLL-en, lastes denne DLL-en inn. Hvis Windows imidlertid ikke finner DLL-en i noen av katalogene i søkerekkefølgen for DLL-en, returneres en feil i innlastingsoperasjonen av DLL-en. Følgende er DLL-søkerekkefølgen for LoadLibrary-og LoadLibraryEx-funksjonene,som brukes til å laste inn dynamiske dynamiske koblingslinjer:

1. Katalogen som programmet lastet inn fra

2. Systemkatalogen

3. 16-biters systemkatalog

4. Windows-katalogen

5. Gjeldende arbeidskatalog (CWD)

6. Katalogene som er oppført i path-miljøvariabelen

Tenk deg følgende:

• Et program laster inn en DLL-fil uten å angi en fullstendig bane som programmet forventer å finne i CWD-en for programmet.

• Programmet er klargjort til å håndtere saken når dll-en ikke blir funnet.

• Angriperen kjenner til denne informasjonen om programmet og styrer CWD-en.

• Angriperen kopierer sin egen spesialopprettede versjon av DLL-en i CWD. Dette forutsetter at angriperen har tillatelse til å gjøre dette.

• Windows søker gjennom katalogene i søkerekkefølgen for DLL-en og finner DLL-en i CWD-en for programmet.

I dette scenarioet kjører den spesialopprettede DLL-en i programmet og får rettighetene til den gjeldende brukeren.

Anbefaling For å forhindre dette angrepet kan programmer fjerne den gjeldende arbeidskatalogen (CWD) fra dll-søkebanen ved å kalle
opp SetDllDirectory-API-en ved hjelp av en tom streng
(""). Hvis et program er avhengig av innlasting av en DLL-fil fra den gjeldende katalogen, kan du hente den gjeldende arbeidskatalogen og bruke den til å sende i en fullstendig bane til LoadLibrary.



Vi er også oppmerksomme på at enkelte utviklere bruker LoadLibrary til å validere om en bestemt DLL-fil er til stede for å fastslå hvilken versjon av Windows som kjøres av brukeren. Vær oppmerksom på at dette kan gjøre programmet sårbart. Hvis det berørte biblioteket faktisk ikke finnes på Windows-versjonen som programmet er utført på, kan en angriper introdusere et bibliotek med samme navn i CWD. Vi anbefaler på det sterkeste at du ikke bruker denne teknikken. Bruk i stedet de anbefalte metodene som er beskrevet i MSDN-artikkelen «Henter systemversjonen».

Et program som laster inn tredjeparts plugin-moduler, og som ikke kan tvinge plugin-modulene til å bruke en kvalifisert bane for LoadLibrary-samtaler, skal kalle SetDllDirectory("") for å fjerne CWD og deretter kalle SetDllDirectory("plassering for plugin-installasjon") for å legge til installasjonskatalogen for plugin-modulen i dll-søkebanen.

SearchPath-baserte angrep

Et lignende angrep finnes når et program bruker SearchPath API til å finne en DLL-fil og laste inn banen som returneres av SearchPath. Følgende er standard søkerekkefølge for SearchPath API:

• Katalogen som programmet lastet inn fra

• Gjeldende arbeidskatalog (CWD)

• Systemkatalogen

• 16-biters systemkatalog

• Windows-katalogen

• Katalogene som er oppført i path-miljøvariabelen

Vi anbefaler ikke dette mønsteret fordi det ikke er sikkert. Vi anbefaler ikke SearchPath-funksjonen som en metode for å finne en .dll-fil hvis den tiltenkte bruken av utdataene er i et kall til LoadLibrary-funksjonen. Dette kan føre til at du finner feil .dll-fil fordi søkerekkefølgen til SearchPath-funksjonen er forskjellig fra søkerekkefølgen som brukes av LoadLibrary-funksjonen. Hvis du må finne og laste inn en DLL-fil, bruker du LoadLibrary-funksjonen.

ShellExecute og CreateProcess

Variasjoner av disse problemene kan også finnes når utviklere kaller lignende funksjoner, for eksempel ShellExecuteog CreateProcess,for å laste inn eksterne kjørbare filer. Vi anbefaler at utviklere er forsiktige når de laster inn binære filer, og angir den fullstendige banen. Dette bør utgjøre mindre kompleksitet når du laster inn en binærfil i stedet for et bibliotek.

Veiledning om identifisering av belastninger for usikkert bibliotek

I kildekode er følgende eksempler på at usikkert bibliotek lastes inn:

• I følgende kodeeksempel søker programmet etter "schannel.dll" ved hjelp av den minst sikre søkebanen. Hvis en angriper kan plassere schannel.dll i CWD, lastes den inn selv før programmet søker i Windows-katalogene etter det riktige biblioteket.

  DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
  HMODULE handle = LoadLibrary(result);

• I følgende kodeeksempel prøver programmet å laste inn biblioteket fra de ulike plasseringene for programmet og operativsystemet som er beskrevet i begynnelsen av dette dokumentet for LoadLibrary()-kallet. Hvis det er risiko for at filen ikke er til stede, kan programmet prøve å laste inn filen fra gjeldende arbeidskatalog. Dette scenarioet er litt mindre farlig enn i forrige eksempel. Programmet er imidlertid fortsatt utsatt for risiko hvis miljøet ikke er fullstendig forutsigbart.

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

Følgende er eksempler på bedre og sikrere bibliotekbelastninger:

• I følgende kodeeksempel lastes biblioteket direkte inn ved hjelp av en fullstendig bane. Det er ingen risiko for at angriperen introduserer skadelig kode med mindre han allerede har skrivetillatelser til programmets målkatalog.
  
  

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

  
  
  Obs! Hvis du vil ha informasjon om hvordan du fastslår systemkatalogen, kan du se følgende ressurser:
  
  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

• I følgende kodeeksempel fjernes den gjeldende arbeidskatalogen fra søkebanen før LoadLibrary kalles. Dette reduserer risikoen betydelig siden angriperen må kontrollere enten programkatalogen, Windows-katalogen eller eventuelle kataloger som er angitt i brukerens bane for å kunne bruke et DLL-forhåndslastingsangrep.

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

• I alle systemer som har installert sikkerhetsoppdatering 963027 (beskrevet i MS09-014),vil følgende kode permanent flytte CWD til siste punkt i søkerekkefølgen. Eventuelle senere anrop til SetSearchPathMode-funksjonen i denne prosessen som prøver å endre søkemodus, vil mislykkes.

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

• I følgende kodeeksempel fjernes den gjeldende arbeidskatalogen fra søkebanen før LoadLibrary kalles. Dette reduserer risikoen betydelig siden angriperen må kontrollere enten programkatalogen, Windows-katalogen eller eventuelle kataloger som er angitt i brukerens bane for å kunne bruke et DLL-forhåndslastingsangrep.

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