Säker inläsning av bibliotek för att förhindra DLL-förinläsningsattacker

LoadLibrary-baserade attacker

När ett program dynamiskt läser in en DLL utan att ange en helt kvalificerad sökväg försöker Windows hitta DLL-filen genom att linjärt söka igenom en väldefinierad uppsättning kataloger, som kallas DLL-sökordning. Om Windows hittar DLL-filen i DLL-sökordningen läses DLL-filen in. Men om Windows inte hittar DLL-filen i någon av katalogerna i DLL-sökordningen returneras ett fel i DLL-inläsningen. Följande är DLL-sökordningen för funktionerna LoadLibraryoch LoadLibraryEx,som används för att läsa in DLL-filer dynamiskt:

1. Katalogen som programmet läses in från

2. Systemkatalogen

3. 16-bitars systemkatalogen

4. Windows-katalogen

5. Aktuell arbetskatalog (CWD)

6. Katalogerna som visas i PATH-miljövariabeln

Tänk dig följande scenario:

• Ett program läser in en DLL utan att ange en helt kvalificerad sökväg som förväntas hitta i programmets CWD.

• Programmet är redo att hantera ärendet när DLL-filen inte hittas.

• Attackeraren känner till den här informationen om programmet och kontrollerar CWD.

• Attackeraren kopierar sin egen specialut utformade version av DLL-filen i CWD. Det här förutsätter att attackeraren har behörighet att göra detta.

• Windows söker igenom kataloger i DLL-sökordningen och hittar DLL-filen i programmets CWD.

I det här scenariot körs det special utformade DLL-programmet inom programmet och får den aktuella användaren behörighet.

Rekommendation För att förhindra den här attacken kan program ta bort den aktuella arbetskatalogen (CWD) från DLL-sökvägen genom att anropa

SetDllDirectory API med en tom sträng (""). Om ett program är beroende av inläsning av ett DLL-bibliotek från den aktuella katalogen hämtar du den aktuella arbetskatalogen och använder den för att överföra en fullständigt kvalificerad sökväg till LoadLibrary.



Vi är även medvetna om att vissa utvecklare använder LoadLibrary för att verifiera om det finns ett visst DLL-bibliotek för att avgöra vilken version av Windows användaren kör. Du bör vara medveten om att det kan göra programmet sårbart. Om det aktuella biblioteket faktiskt inte finns i Den Windows-version som programmet körs på kan en attackerare introducera ett bibliotek med samma namn i CWD. Vi rekommenderar starkt mot att använda den här metoden. Använd istället de rekommenderade teknikerna som beskrivs i MSDN-artikeln "Hämtar systemversionen".

Ett program som läser in plugin-program från tredje part och som inte kan tvinga plugin-program att använda en kvalificerad sökväg för sina LoadLibrary-anrop bör anropa SetDllDirectory("") för att ta bort CWD och sedan anropa SetDllDirectory("plugin install location") för att lägga till plugin-installationskatalogen i DLL-söksökvägen.

SearchPath-baserade attacker

En liknande attack förekommer när ett program använder SearchPath API för att hitta en DLL och dynamiskt läsa in sökvägen som returneras av SearchPath. Följande är standardsökordningen för SearchPath API:

• Katalogen som programmet läses in från

• Aktuell arbetskatalog (CWD)

• Systemkatalogen

• 16-bitars systemkatalogen

• Windows-katalogen

• Katalogerna som visas i PATH-miljövariabeln

Vi rekommenderar inte det här mönstret eftersom det inte är säkert. Vi rekommenderar inte funktionen SearchPath som metod för att hitta en DLL-fil om den avsedda användningen av utdata används i ett anrop till funktionen LoadLibrary. Det kan resultera i att fel DLL-fil hittas eftersom sökordningen för SearchPath-funktionen skiljer sig från sökordningen som används av funktionen LoadLibrary. Om du behöver hitta och läsa in en DLL-fil använder du funktionen LoadLibrary.

ShellExecute och CreateProcess

Varianter av dessa problem kan också finnas när utvecklare anropar liknande funktioner som ShellExecuteoch CreateProcessför att läsa in externa körbara filer. Vi rekommenderar att utvecklare är försiktig när de läser in binärfiler och anger den fullständigt kvalificerade sökvägen. Det bör vara mindre invecklat när du läser in en binär fil i stället för ett bibliotek.

Vägledning för identifiering av icke-osäkra biblioteksbelastningar

I källkoden är följande exempel på icke-osäkra biblioteksbelastningar:

• I följande kodexempel söker programmet efter "schannel.dll" med hjälp av den minst säkra söksökvägen. Om en attack kan placera schannel.dll i CWD läses den in även innan programmet söker i Windows-katalogerna efter rätt bibliotek.

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

• I följande kodexempel försöker programmet läsa in biblioteket från de olika program- och operativsystemsplatserna som beskrivs i början av det här dokumentet för samtalet LoadLibrary(). Om det finns någon risk att filen inte finns kan programmet försöka läsa in filen från den aktuella arbetskatalogen. Det här scenariot är något mindre farligt än i föregående exempel. Men programmets användare kan utsättas för risker om miljön inte är helt förutsägbar.

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

Följande är exempel på bättre och säkrare biblioteksbelastningar:

• I följande kodexempel läses biblioteket in direkt med hjälp av en fullständigt kvalificerad sökväg. Det finns ingen risk för att attackeraren introducerar skadlig kod om han inte redan har skrivbehörighet till programmets målkatalog.
  
  

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

  
  
  Obs! Mer information om hur du fastställer systemkatalogen finns i följande resurser:
  
  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öljande kodexempel tas den aktuella arbetskatalogen bort från söksökvägen innan ett inläsningsbibliotek anropas. Det här minskar risken avsevärt eftersom attackeret skulle behöva styra antingen programkatalogen, Windows-katalogen eller kataloger som anges i användarens sökväg för att kunna använda ett DLL-förinläsningsangrepp.

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

• På alla system som har installerat säkerhetsuppdatering 963027 (beskrivs i MS09-014)flyttar följande kod permanent CWD till den allra sista platsen i sökordningen. Senare anrop till funktionen SetSearchPathMode inifrån processen som försöker ändra sökläge misslyckas.

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

• I följande kodexempel tas den aktuella arbetskatalogen bort från söksökvägen innan ett inläsningsbibliotek anropas. Det här minskar risken avsevärt eftersom attackeret skulle behöva styra antingen programkatalogen, Windows-katalogen eller kataloger som anges i användarens sökväg för att kunna använda ett DLL-förinläsningsangrepp.

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