Zabezpieczanie ładowania bibliotek w celu zapobiegania atakom ładowania wstępnego bibliotek DLL

Ataki oparte na ładowarce

Gdy aplikacja dynamicznie ładuje bibliotekę DLL bez określania w pełni kwalifikowanej ścieżki, system Windows próbuje znaleźć tę bibliotekę DLL, wyszukując liniowo przez dobrze zdefiniowany zestaw katalogów, nazywany kolejnością wyszukiwania dll. Jeśli system Windows znajdzie bibliotekę DLL w kolejności wyszukiwania biblioteki DLL, załaduje ją. Jeśli jednak system Windows nie znajdzie biblioteki DLL w żadnym z katalogów w kolejności wyszukiwania bibliotek DLL, zwróci niepowodzenie operacji ładowania biblioteki DLL. Poniżej przedstawiono kolejność wyszukiwania bibliotek DLL dla funkcji LoadLibrary iLoadLibraryEx,które są używane do dynamicznego ładowania bibliotek DLL:

1. Katalog, z którego aplikacja załadowała

2. Katalog systemowy

3. 16-bitowy katalog systemowy

4. Katalog systemu Windows

5. Bieżący katalog roboczy (CWD)

6. Katalogi wymienione w zmiennej środowiskowej PATH

Rozważmy następujący scenariusz:

• Aplikacja ładuje bibliotekę DLL bez określania w pełni kwalifikowanej ścieżki, która spodziewa się znaleźć w pliku CWD aplikacji.

• Aplikacja jest w pełni przygotowana do obsługi przypadku, gdy biblioteka DLL nie znajdzie biblioteki DLL.

• Atakujący zna te informacje na temat aplikacji i kontroluje CWD.

• Atakujący kopiuje własną, specjalnie spreparowaną wersję biblioteki DLL w CWD. To założenie zakłada, że atakujący ma na to zgodę.

• System Windows przeszukuje katalogi w kolejności wyszukiwania bibliotek DLL i znajduje bibliotekę DLL w pliku CWD aplikacji.

W tym scenariuszu specjalnie spreparowana biblioteka DLL działa w aplikacji i uzyskuje uprawnienia bieżącego użytkownika.

Zalecenie Aby zapobiec temu atakowi, aplikacje mogą usunąć bieżący katalog roboczy (CWD) ze ścieżki wyszukiwania biblioteki DLL, wywołując interfejs
API SetDllDirectory, używając pustego ciągu
(""). Jeśli aplikacja zależy od ładowania biblioteki DLL z bieżącego katalogu, uzyskaj bieżący katalog roboczy i użyj go, aby przekazać w pełni kwalifikowaną ścieżkę biblioteki LoadLibrary.



Wiemy również, że niektórzy deweloperzy używają biblioteki LoadLibrary do sprawdzania, czy istnieje konkretną biblioteka DLL, aby określić, która wersja systemu Windows jest uruchamiana przez użytkownika. Należy pamiętać, że może to nachłonić aplikację. Jeśli biblioteka, w związku z czym ta biblioteka rzeczywiście nie istnieje w wersji dla systemu Windows, w związku z czym aplikacja jest wykonywana, atakujący może wprowadzić bibliotekę o tej samej nazwie do CWD. Zdecydowanie zalecamy używanie tej techniki. Zamiast tego użyj zalecanych technik opisanych w artykule w witrynie MSDN "Uzyskiwanie wersji systemu".

Aplikacja, która ładuje wtyczki innych firm i nie może wymusić używania kwalifikowanej ścieżki do połączeń LoadLibrary, powinna wywołać SetDllDirectory(""), aby usunąć CWD, a następnie wywołać SetDllDirectory("lokalizacja instalacji wtyczki") w celu dodania katalogu instalacji wtyczki do ścieżki wyszukiwania biblioteki DLL.

Ataki oparte na programie SearchPath

Podobny atak występuje, gdy aplikacja używa interfejsu API SearchPath w celu zlokalizowania biblioteki DLL i dynamicznego ładowania ścieżki zwróconej przez program SearchPath. Domyślna kolejność wyszukiwania interfejsu API programu SearchPath jest następująca:

• Katalog, z którego aplikacja załadowała

• Bieżący katalog roboczy (CWD)

• Katalog systemowy

• 16-bitowy katalog systemowy

• Katalog systemu Windows

• Katalogi wymienione w zmiennej środowiskowej PATH

Nie zalecamy tego wzorca, ponieważ nie jest bezpieczny. Funkcja SearchPath nie jest zalecana podczas lokalizowania pliku dll, jeśli dane wyjściowe mają zostać użycia w wywołaniu funkcji LoadLibrary. Może to spowodować zlokalizowanie niewłaściwego pliku dll, ponieważ kolejność wyszukiwania funkcji SearchPath różni się od kolejności wyszukiwania używanej przez funkcję LoadLibrary. Jeśli musisz znaleźć i załadować plik dll, użyj funkcji LoadLibrary.

ShellExecute i CreateProcess

Odmiany tych problemów mogą również istnieć, gdy deweloperzy wywołają podobne funkcje, takie jak ShellExecutei CreateProcess,aby załadować zewnętrzne pliki wykonywalne. Zalecamy, aby deweloperzy uważali podczas ładowania plików binarnych i określili w pełni kwalifikowaną ścieżkę. Powinno to oznaczać mniejszą złożoność podczas ładowania danych binarnych zamiast biblioteki.

Wskazówki dotyczące identyfikowania niezabezpieczonych ładowania bibliotek

Oto przykłady niezabezpieczonych ładowania bibliotek w kodzie źródłowym:

• W poniższym przykładzie kodu aplikacja wyszukuje "schannel.dll" przy użyciu najmniej bezpiecznej ścieżki wyszukiwania. Jeśli atakujący może umieścić schannel.dll CWD, załaduje się nawet przed wyszukaniem przez aplikację katalogów systemu Windows odpowiedniej biblioteki.

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

• W poniższym przykładzie kodu aplikacja próbuje załadować bibliotekę z różnych lokalizacji aplikacji i systemu operacyjnego opisanych na początku tego dokumentu dla wywołania LoadLibrary(). Jeśli istnieje ryzyko, że plik nie istnieje, aplikacja może spróbować załadować plik z bieżącego katalogu roboczego. Ten scenariusz jest nieco mniej niebezpieczny niż w poprzednim przykładzie. Jednak nadal narazić użytkownika aplikacji na ryzyko, jeśli środowisko nie jest do końca przewidywalne.

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

Poniżej przedstawiono przykłady lepszego i bezpieczniejszego ładowania bibliotek:

• W poniższym przykładzie kodu biblioteka jest ładowana bezpośrednio przy użyciu w pełni kwalifikowanej ścieżki. Nie ma ryzyka, że atakujący wprowadzi złośliwy kod, chyba że ma już uprawnienia do zapisu w katalogu docelowym aplikacji.
  
  

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

  
  
  Uwaga Aby uzyskać informacje na temat określania katalogu systemowego, zobacz następujące zasoby:
  
  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

• W poniższym przykładzie kodu bieżący katalog roboczy jest usuwany ze ścieżki wyszukiwania przed wywołaniem ustawienia LoadLibrary. Znacznie zmniejsza to ryzyko, ponieważ w celu użycia ataków typu wstępnego ładowania DLL atakujący musiałby kontrolować katalog aplikacji, katalog systemu Windows lub wszelkie katalogi określone na ścieżce użytkownika.

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

• We wszystkich systemach, w których zainstalowano aktualizację zabezpieczeń 963027 (opisaną w ms09-014),poniższy kod trwale przeniesie CWD na ostatnie miejsce w kolejności wyszukiwania. Późniejsze wywołania funkcji SetSearchPathMode z tego procesu, które spróbują zmienić tryb wyszukiwania, nie powiodą się.

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

• W poniższym przykładzie kodu bieżący katalog roboczy jest usuwany ze ścieżki wyszukiwania przed wywołaniem ustawienia LoadLibrary. Znacznie zmniejsza to ryzyko, ponieważ w celu użycia ataków typu wstępnego ładowania DLL atakujący musiałby kontrolować katalog aplikacji, katalog okien lub wszelkie katalogi określone na ścieżce użytkownika.

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