Świadczenie pomocy technicznej dla systemu Windows Vista z dodatkiem Service Pack 1 (SP1) kończy się 12 lipca 2011 r. Aby w dalszym ciągu otrzymywać aktualizacje zabezpieczeń dla systemu Windows, należy korzystać z systemu Windows Vista z dodatkiem Service Pack 2 (SP2). Aby uzyskać więcej informacji, zobacz tę stronę internetową firmy Microsoft: Kończy się wsparcie techniczne dla niektórych wersji systemu Windows.

Gdy aplikacja dynamicznie ładuje bibliotekę linków dynamicznych (DLL) bez określania w pełni kwalifikowanej ścieżki, system Windows próbuje zlokalizować bibliotekę DLL, przeszukując dobrze zdefiniowany zestaw katalogów. Jeśli atakujący uzyska kontrolę nad jednym z katalogów, może wymusić załadowanie przez aplikację złośliwej kopii biblioteki DLL zamiast biblioteki DLL, która była oczekiwana. Te ataki są nazywane "atakami ładowania wstępnego bibliotek DLL" i są typowe dla wszystkich systemów operacyjnych, które obsługują dynamiczne ładowanie bibliotek DLL udostępnionych. Skutkiem takich ataków może być to, że atakujący może wykonywać kod w kontekście użytkownika, który uruchamia aplikację. Podczas uruchamiania aplikacji jako administrator może to prowadzić do lokalnego podwyższenia uprawnień. Wiemy o odnowieniu zainteresowania tymi atakami. Aby ograniczyć wpływ tego problemu na naszych wspólnych klientów, udostępniamy ten dokument społeczności deweloperów, aby upewnić się, że wie o tym problemie i ma narzędzia niezbędne do rozwiązania tego problemu w swoich aplikacjach.

Podsumowanie

Opis ataków na wstępne ładowanie biblioteki 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.

Zalecane czynności dla deweloperów oprogramowania

Zalecamy, aby deweloperzy zrobili tak:

  • Sprawdź, czy ich aplikacje są ładowane w przypadku niezabezpieczonych bibliotek (przykłady wszystkich z nich podano w dalszej części tego artykułu). Są to między innymi następujące elementy:

    • Używanie programu SearchPath do identyfikowania lokalizacji biblioteki lub składnika.

    • Używanie oprogramowania LoadLibrary do identyfikowania wersji systemu operacyjnego.

  • Użyj w pełni kwalifikowanych ścieżek dla wszystkich wywołań loadLibrary, CreateProcess i ShellExecute, gdzie możesz.

  • Aby usunąć bieżący katalog roboczy z domyślnej kolejności wyszukiwania biblioteki DLL, gdy jest wymagane, zaimresuj wywołania setdlldirectory z pustym ciągiem (""). Należy pamiętać, że ustawienie SetDllDirectory ma wpływ na cały proces. Dlatego należy to zrobić raz na wczesnym etapie procesu inicjowania, a nie przed i po wywołaniu ładowaniaLibrary. Ponieważ ustawienie SetDllDirectory wpływa na cały proces, wiele wątków wywołującego setdlldirectory z różnymi wartościami może powodować niezdefiniowane zachowanie. Ponadto, jeśli proces został zaprojektowany w celu ładowania bibliotek DLL innych firm, konieczne będzie przetestowanie w celu określenia, czy ustawienie dla całego procesu będzie powodować niezgodności. Znanym problemem jest to, że gdy aplikacja zależy od języka Visual Basic for Applications, ustawienie dotyczące całego procesu może powodować niezgodności.

  • Użyj funkcji SetSearchPathMode,aby włączyć tryb wyszukiwania bezpiecznego procesu dla tego procesu. Powoduje to przeniesienie bieżącego katalogu roboczego na ostatnie miejsce na liście wyszukiwania programu SearchPath w okresie istnienia procesu.

  • Unikaj używania programu SearchPath do sprawdzania istnienia biblioteki DLL bez określania w pełni kwalifikowanej ścieżki, nawet jeśli jest włączony tryb bezpiecznego wyszukiwania, ponieważ nadal może to prowadzić do ataków na wstępne ładowanie biblioteki DLL.

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

Dynamiczne wykrywanie niezabezpieczonych ładowania za pomocą Monitora procesu

Firma Microsoft publikuje narzędzie o nazwie Monitor procesu. To narzędzie umożliwia deweloperom i administratorom śledzenie zachowania uruchomionego procesu. Monitor procesu może być używany do dynamicznego wykrywania, czy któraś z aplikacji może być podatna na tego typu problem.

  • Aby pobrać Monitor procesu, odwiedź następującą stronę internetową firmy Microsoft:

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

  • Spróbuj uruchomić aplikację przy użyciu CWD ustawionego na określony katalog. Na przykład kliknij dwukrotnie plik z rozszerzeniem, którego program obsługi plików jest przypisany do aplikacji.

  • Skonfiguruj Monitor procesu przy użyciu następujących filtrów:



    tekst alternatywny

  • W przypadku trafienia ścieżki, która jest podatna na zagrożenia, zobaczysz coś podobnego do następującego: tekst alternatywnyWywołanie do zdalnego udziału plików w celu załadowania biblioteki DLL wskazuje, że jest to program, który jest narażony

    na zagrożenia.

Więcej informacji

Aby uzyskać więcej informacji, odwiedź następujące strony sieci Web firmy Microsoft:

Kolejność wyszukiwania bibliotek linku dynamicznego

http://msdn.microsoft.com/library/ms682586(VS.85).aspxDokumentacja MSDN dotycząca funkcji SearchPath

http://msdn.microsoft.com/library/aa365527(VS.85).aspxDokumentacja MSDN dotycząca funkcji LoadLibrary

http://msdn.microsoft.com/library/ms684175(VS.85).aspxDokumentacja msdn w funkcji SetDllDirectory

http://msdn.microsoft.com/library/ms686203(VS.85).aspxDokumentacja MSDN dotycząca funkcji SetSearchPathMode

http://msdn.microsoft.com/library/dd266735(VS.85).aspxWpis w blogu autorstwa Davida Leblanca, głównego inżyniera zabezpieczeń z pakietem Microsoft Office

http://blogs.msdn.com/b/david_leblanc/archive/2008/02/20/dll-preloading-attacks.aspxWpis w blogu autorstwa Andrew'a Yjnesa, zespołu inżynierów MSRC ds. ataków na wstępne ładowanie bibliotek DLL

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

Dodatkowe materiały

Potrzebna dalsza pomoc?

Rozwijaj swoje umiejętności
Poznaj szkolenia
Uzyskuj nowe funkcje w pierwszej kolejności
Dołącz do niejawnych testerów firmy Microsoft

Czy te informacje były pomocne?

Jaka jest jakość języka?
Co wpłynęło na Twoje wrażenia?

Dziękujemy za opinię!

×