ilyachalov (ilyachalov) wrote,
ilyachalov
ilyachalov

Category:

Безопасность DLL

Начало тут:
1. динамически подключаемые библиотеки;
2. о динамически подключаемых библиотеках подробнее;
3. преимущества динамического связывания;
4. создание динамически подключаемой библиотеки;
5. функция точки входа DLL;
6. динамическое связывание во время запуска;
7. динамическое связывание во время выполнения;
8. порядок поиска DLL;
9. данные библиотеки DLL;
10. перенаправление DLL;
11. обновления DLL.

Перевод с английского статьи от 31.05.2018 г. «Dynamic-Link Library Security»:
https://docs.microsoft.com/ru-ru/windows/win32/dlls/dynamic-link-library-security
(На данный момент на этом сайте нет перевода этой статьи на русский, есть только версия на английском.)

Когда приложение динамически загружает динамически подключаемую библиотеку (DLL) без указания полного пути к ней, операционная система Windows пытается найти эту DLL, запуская поиск по четко определенному списку каталогов в конкретном порядке так, как это описано в статье «Порядок поиска DLL» [мой перевод]. Если злоумышленник получит контроль над одним из каталогов из поискового списка каталогов, составленного для поиска DLL, он сможет поместить зловредную копию разыскиваемой DLL в этот каталог. Такую ситуацию иногда называют атакой на этапе подготовки DLL к загрузке [DLL preloading attack] или атака подсадкой двоичного кода [binary planting attack] [под «подсадкой» (planting) здесь подразумевается подброс зловредной копии DLL в нужный каталог системы по аналогии с высадкой саженцев растений в грунт; под «двоичным кодом» (binary) здесь подразумевается файл зловредной копии DLL]. Если система не найдет нужную DLL до того момента, как поиск достигнет каталога, над которым у злоумышленника есть контроль, то системе придется загрузить зловредную копию искомой DLL, которую злоумышленник поместил в этот каталог. Если приложение при этом запущено с правами администратора системы, то злоумышленник сможет достичь успеха в повышении прав [privilege elevation] в данной [local] системе.

Например, предположим, что приложение запрограммировано загружать DLL из текущего каталога пользователя и совершать контролируемое завершение программы при ошибке [fail gracefully], если DLL не найдена. Приложение вызывает функцию LoadLibrary, задав ей в параметре только имя DLL [а не полный путь к ней], что служит причиной того, что система запускает поиск DLL. Предположим, что включен безопасный режим поиска DLL и приложение не использует альтернативный порядок поиска DLL, тогда система будет обыскивать каталоги в следующем порядке:
  1. каталог, из которого загружено приложение;
  2. системный каталог;
  3. системный каталог для 16-разрядных библиотек DLL;
  4. каталог операционной системы Windows;
  5. текущий каталог;
  6. каталоги, перечисленные в переменной среды PATH.

Продолжим наш пример. Злоумышленник, зная, как работает приложение, получает контроль над текущим каталогом и помещает в него зловредную копию DLL. Когда приложение выполнит вызов функции LoadLibrary, система запустит поиск DLL, найдет зловредную копию DLL в текущем каталоге и загрузит ее. Затем зловредная копия DLL запустится внутри приложения и получит права пользователя.

Разработчики могут помочь своим приложениям защититься от атак на этапе подготовки DLL к загрузке, выполняя следующие рекомендации:
  • везде, где это возможно, указывайте полный путь [к файлу модуля] при вызове функций LoadLibrary, LoadLibraryEx, CreateProcess или ShellExecute в их параметрах;

  • используйте флаги LOAD_LIBRARY_SEARCH при вызове функции LoadLibraryEx в ее параметре или используйте эти флаги при вызове функции SetDefaultDllDirectories в ее параметре, чтобы сформировать нужный порядок поиска DLL, необходимой процессу, а затем используйте функции AddDllDirectory или SetDllDirectory, чтобы модифицировать сформированный ранее поисковый список каталогов. Подробнее об этом читайте в статье «Порядок поиска DLL» [мой перевод].

    Замечание для пользователей (предыдущих по отношению к свежим на дату написания статьи версиям) операционных систем Windows 7 (вики: с 22.10.2009 г.), Windows Server 2008 R2 (вики: с 22.10.2009 г.), Windows Vista (вики: с 30.11.2006 г.) и Windows Server 2008 (вики: с 12.12.2008 г.): указанные выше в этом пункте флаги и функции доступны на этих системах с момента установки обновления KB2533623;

  • для операционных систем Windows, указанных в замечании выше, с установленным обновлением KB2533623, выполняйте рекомендацию из второго пункта;

  • рассмотрите возможность использования перенаправления DLL [мой перевод] или манифеста, чтобы гарантировать, что ваше приложение использует корректную [не зловредную] DLL;

  • при использовании стандартного порядка поиска DLL убедитесь, что включен безопасный режим поиска DLL. Включение этого режима помещает текущий каталог пользователя позже в очередности хода поиска, увеличивая вероятность того, что операционная система Windows найдет корректную [не зловредную] копию DLL раньше зловредной. Безопасный режим поиска DLL включен по умолчанию в операционных системах Windows, начиная с операционной системы «Windows XP» с установленным пакетом обновления SP2, и этот режим управляется параметром реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode. Подробнее об этом читайте в статье «Порядок поиска DLL» [мой перевод];

  • рассмотрите возможность удаления текущего каталога из стандартного поискового списка каталогов при поиске DLL, это можно сделать посредством вызова функции SetDllDirectory с указанием в ее параметре пустой строки "". Это нужно сделать один раз как можно раньше при инициализации процесса, не перед самым вызовом или после вызова функции LoadLibrary. Имейте в виду, что функция SetDllDirectory воздействует на весь процесс целиком и что множество потоков выполнения, вызывающих функцию SetDllDirectory одновременно, но с заданием различных значений для ее параметра, может послужить причиной неопределенного поведения. Если ваше приложение загружает библиотеки DLL третьей стороны, протестируйте их очень внимательно, чтобы выявить любые несовместимости;

  • не используйте функцию SearchPath, чтобы получить путь к DLL для последующего вызова функции LoadLibrary, пока для процесса не включен безопасный режим поиска. Когда этот режим не включен, функция SearchPath использует не такой порядок поиска, как функция LoadLibrary, и очень возможно, что функция SearchPath в поисках указанной в ее параметре DLL сначала обыщет текущий каталог пользователя. Чтобы включить в разрезе процесса безопасный режим поиска для функции SearchPath, используйте функцию SetSearchPathMode с указанием в ее параметре флага BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Такой вызов этой функции передвигает текущий каталог в конец поискового списка каталогов функции SearchPath на период времени жизни процесса. Отметим, что текущий каталог не удаляется из поискового списка каталогов вообще, так что, если система не найдет корректную [не зловредную] копию DLL перед тем, как она достигнет в поисковом списке каталогов текущего каталога, приложение всё еще останется уязвимым для атаки. Как и в случае с функцией SetDllDirectory, вызов функции SetSearchPathMode должен быть выполнен как можно раньше при инициализации процесса и этот вызов повлияет на весь процесс целиком. Если ваше приложение загружает библиотеки DLL третьей стороны, протестируйте их очень внимательно, чтобы выявить любые несовместимости;

  • не пытайтесь определять версию операционной системы [в которой запущено ваше приложение], основываясь на вызове функции LoadLibrary, которая ищет DLL. Если приложение запущено в операционной системе, в которой эта DLL обоснованно отсутствует [как я понял, некоторые программисты пытаются определить версию операционной системы по отсутствию каких-то DLL, специфичных для определенных версий операционных систем], то нужно учитывать возможность того, что в данной операционной системе присутствует зловредная копия DLL [маскирующаяся под разыскиваемую DLL] в обыскиваемых каталогах, и в таком случае она и будет загружена процессом. Вместо такого способа [определения версии операционной системы] используйте рекомендованную методику, описанную в статье «Определение версии операционной системы».

Утилита «Process Monitor» [вики, с 1996 г.] [по-русски «монитор процессов»] может помочь найти те операции по загрузке DLL, которые могут являться уязвимыми для атак злоумышленников. Эту утилиту можно скачать отсюда:
https://docs.microsoft.com/ru-ru/sysinternals/downloads/procmon
[на момент перевода данной статьи по этому адресу доступна версия 3.53 утилиты от 18.12.2019 г.].

Следующий порядок действий описывает, как использовать утилиту «Process Monitor», чтобы проверить [на уязвимости] операции по загрузке библиотек DLL, выполняемые вашим приложением.

Использование утилиты «Process Monitor» для проверки операций по загрузке DLL, выполняемых вашим приложением
  1. Запустите утилиту «Process Monitor».

  2. В утилите «Process Monitor» включите следующие фильтры:
    • по операции CreateFile;
    • по операции LoadImage;
    • по пути, содержащему .cpl;
    • по пути, содержащему .dll;
    • по пути, содержащему .drv;
    • по пути, содержащему .exe;
    • по пути, содержащему .ocx;
    • по пути, содержащему .scr;
    • по пути, содержащему .sys.

  3. Установите исключение по следующим фильтрам:
    • по имени процесса procmon.exe;
    • по имени процесса Procmon64.exe;
    • по имени процесса System;
    • по операциям, начинающимся с IRP_MJ_;
    • по операциям, начинающимся с FASTIO_;
    • по результату SUCCESS;
    • по пути, заканчивающемуся на pagefile.sys.

  4. Запустите ваше приложение так, чтобы текущий каталог пользователя был установлен в конкретный каталог. Например, можно дважды кликнуть мышкой на файл с расширением, привязанным к вашему приложению.

  5. Проверьте окно утилиты «Process Monitor», в котором будет выведен результатный список процессов с учетом установленных фильтров и исключений, в поисках путей, выглядящих подозрительно, таких как обращение к текущему каталогу пользователя для загрузки DLL. Такой вид обращения может указывать на уязвимость в вашем приложении.
Tags: Английский язык, Образование, Программирование
Subscribe

  • Сценарий фильма, который никогда не снимут

    Залпом прочитал набросок сценария художественного фильма, который в 2015-2016 годах написал в своем ЖЖ Григорий Циденков в десяти постах: 1.…

  • Непрощенный, 1992, кино

    Фильм очень понравился. Первый раз смотрел в 90-х, почти ничего не запомнил. Недавно пересмотрел дважды. После «долларовой трилогии» запустил на…

  • Вероятности в сериале «Менталист»

    В первой серии второго сезона сериала «Менталист» (серия называется «Искупление») сотрудники КБР обыскивают помещение, в котором полиция нашла убитую…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments