Безопасно зареждане на библиотеки, за да се предотвратят атаките с предварително напълнене в DLL

Атаки, базирани на зареждането

Когато дадено приложение се зарежда динамично, без да се указва напълно квалифициран път, Windows се опитва да намери този DLL, като линейно търси в добре дефиниран набор от директории, известни като ред за търсене на DLL. Ако Windows открие DLL в реда за търсене на DLL, той ще зареди този DLL. Ако обаче Windows не намери DLL файла в коя да е от директориите в реда за търсене на DLL, той ще върне неуспешно операцията за натоварване на DLL. Следва реда за търсене на DLL за функциите зарежданетои LoadLibraryEx, които се използват за динамично зареждане на DLL файлове:

1. Директорията, от която е заредено приложението

2. Системният указател

3. 16-битовият системен указател

4. Указателя на Windows

5. Текущия работен указател (ХИБ)

6. Указателите, които са изредени в променливата за средата PATH

Обмислете следния сценарий:

• Приложението зарежда DLL, без да указва напълно квалифициран път, който той очаква да намери в ХИБ на приложението.

• Приложението е напълно подготвено да обработи случая, когато не намери DLL.

• Нападателят знае тази информация за приложението и управлява ХИБ.

• Нападателят копира собствената си специално създадена версия на DLL в ХИБ. Това предполага, че Нападателят има разрешение да прави това.

• Windows търси в директориите в реда за търсене на DLL и намира DLL в ХИБ на приложението.

В този случай специално изработеният DLL се изпълнява в приложението и печели привилегиите на текущия потребител.

Препоръка

за да предотвратите тази атака, приложенията могат да премахнат текущия работен указател (ХИБ) от пътя за търсене на DLL, като извикат API за SetDllDirectory с помощта на празен низ (""). Ако дадено приложение зависи от зареждането на DLL от текущия указател, моля, Получете текущия работен указател и го използвайте, за да преминете в напълно квалифициран път за зареждането.



Също така сме наясно, че някои разработчици използват зареждането, за да проверят дали определен DLL е наличен, за да се определи коя версия на Windows се изпълнява от потребителя. Трябва да знаете, че това може да направи приложението уязвимо. Ако засегнатата библиотека наистина не съществува в изданието на Windows, на което се изпълнява приложението, атакуващият може да въведе библиотека със същото име в ХИБ. Горещо ви препоръчваме да използвате тази техника. Вместо това използвайте препоръчваните техники, които са описани в статията в MSDN, "получаване на системната версия"

. Приложение, което зарежда добавки от други разработчици и което не може да принуди добавките да използват квалифициран път за своите зареждането повиквания, трябва да се обадите на SetDllDirectory (""), за да премахнете ХИБ и след това да се обадите SetDllDirectory ("местоположение за инсталиране на добавката"), за да добавите добавката за инсталиране на добавката на директорията за търсене.

Атаки, базирани на SearchPath

Подобна атака съществува, когато дадено приложение използва API на SearchPath, за да намери DLL и динамично зареждане на пътя, върнат от SearchPath. По-долу е редът на търсене по подразбиране за API на SearchPath:

• Директорията, от която е заредено приложението

• Текущия работен указател (ХИБ)

• Системният указател

• 16-битовият системен указател

• Указателя на Windows

• Указателите, които са изредени в променливата за средата PATH

Не препоръчваме този шаблон, тъй като не е защитен. Не препоръчваме функцията SearchPath като метод за намиране на. dll файл, ако предназначението на изхода е в разговор с функцията зареждането. Това може да доведе до намирането на грешен. dll файл, защото редът на търсене на функцията SearchPath се различава от реда на търсене, използван от функцията зареждането. Ако трябва да намерите и заредите. dll файл, използвайте функцията зареждането.

ShellExecute и CreateProcess

Вариациите на тези проблеми могат да съществуват и когато разработчиците извикват подобни функции, като например ShellExecuteи CreateProcess, за да зареждат външни изпълними файлове. Препоръчваме разработчиците да бъдат внимателни, когато зареждат двоични файлове и указват напълно квалифицирания път. Това би трябвало да представлява по-малко сложност, когато зареждате двоично вместо библиотека.

Ръководство за идентифициране на незащитените натоварвания на библиотеката

В изходния код по-долу са дадени примери за незащитени натоварвания на библиотека:

• В следващия пример за код приложението търси "schannel.dll", като използва поне път за защитено търсене. Ако атакуващият може да постави schannel.dll в ХИБ, той ще се зареди още преди приложението да търси в указателя на Windows за съответната библиотека.

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

• В следващия пример за код приложението се опитва да зареди библиотеката от различните местоположения на приложения и операционни системи, описани в началото на този документ за зареждането () повикване. Ако има някакъв риск, че файлът не е наличен, приложението може да се опита да зареди файла от текущата работна директория. Този сценарий е малко по-опасен от предишния пример. Обаче той все още излага потребителя на приложението на риск, ако околната среда не е напълно предвидим.

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

По-долу са дадени примери на по-добре, по-сигурни натоварвания на библиотека:

• В следващия пример за код библиотеката се зарежда директно с помощта на напълно квалифициран път. Няма риск Нападателят да въвежда злонамерен код, освен ако той вече няма разрешения за писане в указателя на приложението.
  
  

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

  
  
  Забележка за информация как да определите указателя на системата, вижте следните ресурси:
  
  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

• В следващия примерен код текущата работна директория е премахната от пътя за търсене, преди да се обадите на зареждането. Това значително намалява риска, тъй като атакуващият ще трябва да управлява или директорията на приложението, директорията на Windows, или всички указатели, които са зададени в пътя на потребителя, за да се използва DLL предварително заредена атака.

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

• На всички системи, които имат инсталирана актуализация за защита 963027 (описана в MS09-014), кодът по-долу ще бъде окончателно преместен на ХИБ до последното място в реда на търсене. Всяко по-късни обаждания към функцията SetSearchPathMode отвътре на този процес, което се опитва да промени режима на търсене, ще бъде неуспешно.

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

• В следващия примерен код текущата работна директория е премахната от пътя за търсене, преди да се обадите на зареждането. Това значително намалява риска, тъй като атакуващият ще трябва да управлява или директорията на приложението, директорията на Windows, или всички указатели, които са зададени в пътя на потребителя, за да се използва DLL предварително заредена атака.

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