Клиент поиска Dll что это такое

Обновлено: 02.07.2024

Система может содержать несколько версий одной библиотеки динамической компоновки (DLL). Приложения могут управлять расположением, из которого загружается библиотека DLL, указывая полный путь или используя другой механизм, например манифест. Если эти методы не используются, система ищет DLL во время загрузки, как описано в этом разделе.

Факторы, влияющие на поиск

Следующие факторы влияют на поиск системой DLL:

  • Если библиотека DLL с таким же именем модуля уже загружена в память, система проверяет только перенаправление и манифест, прежде чем разрешить загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
  • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются) вместо поиска DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.
  • Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это справедливо даже в том случае, если первая библиотека DLL была загружена с указанием полного пути.

Порядок поиска приложений UWP

Когда приложение UWP для Windows 10 (или приложение Магазина для Windows 8.x) загружает упакованный модуль, вызывая функцию LoadPackagedLibrary, библиотека DLL должна находиться в графе зависимостей пакетов процесса. Дополнительные сведения см. в разделе LoadPackagedLibrary. Когда приложение UWP загружает модуль другими способами и не указывает полный путь, система ищет библиотеку DLL и ее зависимости во время загрузки, как описано в этом разделе.

Прежде чем система начнет поиск DLL, она проверяет следующее:

  • Если библиотека DLL с таким же именем модуля уже загружена в память, система использует загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
  • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются). Система не ищет DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

Если система должна искать модуль или его зависимости, она всегда использует порядок поиска для приложений UWP, даже если зависимость не является кодом приложения UWP.

Стандартный порядок поиска для приложений UWP

Если модуль еще не загружен или не находится в списке известных DLL, система ищет эти местоположения в следующем порядке:

    Граф зависимостей пакетов процесса. Это пакет приложения плюс любые зависимости, указанные как

Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это верно, даже если первая DLL была загружена с указанием полного пути.

Альтернативный порядок поиска для приложений UWP

Если модуль изменяет стандартный порядок поиска, вызывая функцию LoadLibraryEx с параметром LOAD_WITH_ALTERED_SEARCH_PATH, система ищет каталог, из которого был загружен указанный модуль, а не каталог вызывающего процесса. Система ищет эти местоположения в следующем порядке:

    Граф зависимостей пакетов процесса. Это пакет приложения плюс любые зависимости, указанные как

Порядок поиска для настольных приложений

Настольные приложения могут управлять расположением, из которого загружается библиотека DLL, путем указания полного пути, использования перенаправления библиотеки DLL или манифеста. Если ни один из этих методов не используется, система ищет DLL во время загрузки, как описано в этом разделе.

Прежде чем система начнет поиск DLL, она проверяет следующее:

  • Если библиотека DLL с таким же именем модуля уже загружена в память, система использует загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
  • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются). Система не ищет DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это верно, даже если первая DLL была загружена с указанием полного пути.

Если злоумышленник получает контроль над одним из каталогов, в которых выполняется поиск, он может поместить в этот каталог вредоносную копию библиотеки DLL.Для способов предотвратить такие атаки, см. Безопасность библиотеки динамической связи.

Стандартный порядок поиска для настольных приложений

Стандартный порядок поиска DLL, используемый системой, зависит от того, включен ли режим поиска Safe DLL или отключен. Безопасный режим поиска DLL помещает текущий каталог пользователя позже в порядке поиска.

Безопасный режим поиска DLL включен по умолчанию. Чтобы отключить эту функцию, создайте значение реестра \ CurrentControlse_machine \ System \ CurrentControlset \ Control \ Session \ SafeContllsearchmode \ Session \ SafeContllsearchmode \ Session \ SafeContllsearchMode В этой теме.

Если включен SafedllSearchmode, порядок поиска выглядит следующим образом:

  1. каталог, из которого загружено приложение.
  2. Системный каталог. Используйте функцию getSystemdirectory, чтобы получить путь этого каталога.
  3. 16-битный системный каталог. Нет функции, которая получает путь этого каталога, но ищется.
  4. каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь этого каталога.
  5. текущий каталог.
  6. каталоги, которые перечислены в переменной среды пути. Обратите внимание, что это не включает путь для каждого приложения, указанный ключом реестра путей приложений. Клавиша путей приложений не используется при вычислении пути поиска DLL.

    Если safedllsearchmode отключен, порядок поиска выглядит следующим образом:

    1. каталог, из которого загружено приложение.
    2. текущий каталог.
    3. Системный каталог. Используйте функцию getSystemdirectory, чтобы получить путь этого каталога.
    4. 16-битный системный каталог. Нет функции, которая получает путь этого каталога, но ищется.
    5. каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь этого каталога.
    6. каталоги, которые перечислены в переменной среды пути. Обратите внимание, что это не включает путь для каждого приложения, указанный ключом реестра путей приложений. Клавиша путей приложений не используется при вычислении пути поиска DLL.

      Заказать альтернативный поиск для настольных приложений

      Стандартный порядок поиска, используемый системой, может быть изменен путем вызова функции LoadLibraryEx с Load_With_Altered_Search_Path. Стандартный порядок поиска также может быть изменен, вызывая функцию SetDLLDirectory.

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

      Если вы укажете альтернативную поисковую стратегию, его поведение продолжается до тех пор, пока все связанные с ними исполняемые модули не будут расположены. После того, как система запускает обработку процедуры инициализации DLL, система возвращается к стандартной стратегии поиска.

      Функция LoadLibraryEx поддерживает альтернативный порядок поиска, если вызов указывает на Load_with_altered_search_Path, а параметр lpfilename указывает абсолютный путь.

      Обратите внимание, что стандартная стратегия поиска и стратегия альтернативных поисков, указанная на LoadLibraryEx с Load_With_Altered_Search_Path, отличается только одним способом: стандартный поиск начинается в каталоге вызова приложения, а альтернативный поиск начинается в каталоге исполняемого модуля, который LoadLibraryEx загрузка.

      Если включено SafedllSearchmode, альтернативный порядок поиска выглядит следующим образом:

      1. каталог, указанный lpfilename .
      2. Системный каталог. Используйте функцию getSystemdirectory, чтобы получить путь этого каталога.
      3. 16-битный системный каталог. Нет функции, которая получает путь этого каталога, но ищется.
      4. каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь этого каталога.
      5. текущий каталог.
      6. каталоги, которые перечислены в переменной среды пути. Обратите внимание, что это не включает путь для каждого приложения, указанный ключом реестра путей приложений. Клавиша путей приложений не используется при вычислении пути поиска DLL.

        Если safedllsearchmode отключен, альтернативный порядок поиска выглядит следующим образом:

        1. каталог, указанный lpfilename .
        2. текущий каталог.
        3. Системный каталог. Используйте функцию getSystemdirectory, чтобы получить путь этого каталога.
        4. 16-битный системный каталог. Нет функции, которая получает путь этого каталога, но ищется.
        5. каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь этого каталога.
        6. каталоги, которые перечислены в переменной среды пути. Обратите внимание, что это не включает путь для каждого приложения, указанный ключом реестра путей приложений.Ключ App Paths не используется при вычислении пути поиска DLL.

        Функция SetDllDirectory поддерживает альтернативный порядок поиска, если параметр lpPathName указывает путь. Альтернативный порядок поиска следующий:

        1. Каталог, из которого загружено приложение.
        2. Каталог, указанный параметром lpPathName в SetDllDirectory.
        3. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу. Имя этого каталога — System32.
        4. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется. Имя этого каталога — System.
        5. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Если параметр lpPathName является пустой строкой, вызов удаляет текущий каталог из порядка поиска.

        SetDllDirectory эффективно отключает безопасный режим поиска DLL, пока указанный каталог находится в пути поиска. Чтобы восстановить безопасный режим поиска DLL на основе значения реестра SafeDllSearchMode и восстановить текущий каталог в соответствии с порядком поиска, вызовите SetDllDirectory с lpPathName равным NULL.

        Порядок поиска с использованием флагов LOAD_LIBRARY_SEARCH

        Приложение может указать порядок поиска, используя один или несколько флагов LOAD_LIBRARY_SEARCH с функцией LoadLibraryEx. Приложение также может использовать флаги LOAD_LIBRARY_SEARCH с функцией SetDefaultDllDirectories, чтобы установить порядок поиска DLL для процесса. Приложение может указать дополнительные каталоги для порядка поиска DLL процесса с помощью функций AddDllDirectory или SetDllDirectory.

        Каталоги, в которых выполняется поиск, зависят от флагов, указанных с помощью SetDefaultDllDirectories или LoadLibraryEx. Если используется более одного флага, соответствующие каталоги ищутся в следующем порядке:

        1. Каталог, содержащий библиотеку DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). В этом каталоге ищутся только зависимости загружаемой библиотеки DLL.
        2. Каталог приложения (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
        3. Пути, явно добавленные с помощью функции AddDllDirectory (LOAD_LIBRARY_SEARCH_USER_DIRS) или функции SetDllDirectory. Если добавлено более одного пути, порядок поиска путей не указан.
        4. Системный каталог (LOAD_LIBRARY_SEARCH_SYSTEM32).

        Если приложение не вызывает LoadLibraryEx с какими-либо флагами LOAD_LIBRARY_SEARCH и не устанавливает порядок поиска DLL для процесса, система ищет библиотеки DLL, используя либо стандартный порядок поиска, либо альтернативный порядок поиска.

        В этой статье описывается, что такое библиотека динамической компоновки (DLL), и различные проблемы, которые могут возникнуть при использовании библиотек DLL. В нем также описаны некоторые дополнительные вопросы, которые следует учитывать при разработке собственных библиотек DLL.

        Относится к: Windows 10 — все выпуски
        Исходный номер базы знаний: 815065

        Обзор

        Описывая, что такое DLL, в этой статье описываются методы динамического связывания, зависимости DLL, точки входа DLL, экспорт функций DLL и средства устранения неполадок DLL.

        Для операционных систем Windows большая часть функциональных возможностей операционной системы обеспечивается DLL. Кроме того, когда вы запускаете программу в одной из этих операционных систем Windows, большая часть функциональных возможностей программы может обеспечиваться библиотеками DLL. Например, некоторые программы могут содержать множество различных модулей, и каждый модуль программы содержится и распространяется в библиотеках DLL.

        Использование библиотек DLL способствует модуляции кода, повторному использованию кода, эффективному использованию памяти и сокращению дискового пространства. Таким образом, операционная система и программы загружаются быстрее, работают быстрее и занимают меньше места на диске компьютера.

        Когда программа использует библиотеку DLL, проблема, называемая зависимостью, может привести к тому, что программа не запустится. Когда программа использует DLL, создается зависимость. Если другая программа перезапишет и разорвет эту зависимость, исходная программа может не запуститься успешно.

        Подробнее

        DLL — это библиотека, содержащая код и данные, которые могут использоваться более чем одной программой одновременно. Например, в операционных системах Windows библиотека DLL Comdlg32 выполняет общие функции, связанные с диалоговыми окнами. Каждая программа может использовать функциональные возможности, содержащиеся в этой библиотеке DLL, для реализации диалогового окна «Открыть». Это способствует повторному использованию кода и эффективному использованию памяти.

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

        Кроме того, обновления легче применять к каждому модулю, не затрагивая другие части программы. Например, у вас может быть программа расчета заработной платы, и налоговые ставки меняются каждый год. Когда эти изменения изолируются в DLL, вы можете применить обновление без повторной сборки или установки всей программы.

        В следующем списке описаны некоторые файлы, реализованные в виде библиотек DLL в операционных системах Windows:

        Файлы элементов управления ActiveX (.ocx)

        Примером элемента управления ActiveX является элемент управления календарем, который позволяет выбрать дату из календаря.

        Файлы панели управления (.cpl)

        Примером файла .cpl является элемент, расположенный на панели управления. Каждый элемент представляет собой специализированную библиотеку DLL.

        Файлы драйверов устройств (.drv)

        Примером драйвера устройства является драйвер принтера, который управляет печатью на принтере.

        Преимущества DLL

        В следующем списке описаны некоторые преимущества, предоставляемые программой, использующей библиотеку DLL:

        Использует меньше ресурсов

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

        Поддерживает модульную архитектуру

        Библиотека DLL помогает разрабатывать модульные программы. Он помогает разрабатывать большие программы, требующие нескольких языковых версий, или программы, требующие модульной архитектуры. Примером модульной программы является бухгалтерская программа, имеющая множество модулей, которые можно динамически загружать во время выполнения.

        Упрощает развертывание и установку

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

        DLL-зависимости

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

        • Зависимая библиотека DLL обновляется до новой версии.
        • Исправлена ​​зависимая библиотека DLL.
        • Зависимая библиотека DLL перезаписывается более ранней версией.
        • Зависимая DLL удаляется с компьютера.

        Эти действия называются конфликтами DLL. Если не обеспечить обратную совместимость, программа может не запуститься.

        В следующем списке описаны изменения, которые были введены в Windows 2000 и более поздних операционных системах Windows, чтобы минимизировать проблемы с зависимостями:

        Защита файлов Windows

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

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

        Инструменты устранения неполадок с DLL

        Для устранения неполадок с DLL доступно несколько инструментов. Следующие инструменты являются одними из этих инструментов.

        Обходчик зависимостей

        Инструмент Dependency Walker может рекурсивно сканировать все зависимые библиотеки DLL, используемые программой. Когда вы открываете программу в Dependency Walker, Dependency Walker выполняет следующие проверки:

        • Dependency Walker проверяет отсутствующие библиотеки DLL.
        • Dependency Walker проверяет наличие недопустимых программных файлов или библиотек DLL.
        • Dependency Walker проверяет соответствие функций импорта и экспорта.
        • Dependency Walker проверяет циклические ошибки зависимостей.
        • Dependency Walker проверяет недействительные модули, поскольку они предназначены для другой операционной системы.

        С помощью Dependency Walker вы можете документировать все библиотеки DLL, используемые программой. Это может помочь предотвратить и исправить проблемы с DLL, которые могут возникнуть в будущем.Dependency Walker находится в следующем каталоге при установке Visual Studio 6.0:

        диск\Program Files\Microsoft Visual Studio\Common\Tools

        Универсальное средство решения проблем DLL

        Универсальный инструмент решения проблем DLL (DUPS) используется для аудита, сравнения, документирования и отображения информации о DLL. В следующем списке описаны утилиты, входящие в состав инструмента DUPS:

        Эта утилита перечисляет все библиотеки DLL на компьютере и записывает информацию в текстовый файл или в файл базы данных.

        Эта утилита сравнивает библиотеки DLL, перечисленные в двух текстовых файлах, и создает третий текстовый файл, содержащий различия.

        Эта утилита загружает текстовые файлы, созданные с помощью утилит Dlister.exe и Dcomp.exe, в базу данных dllHell.

        Эта утилита представляет собой версию утилиты Dtxt2DB.exe с графическим интерфейсом пользователя (GUI).

        База данных справки DLL

        База данных DLL Help помогает найти определенные версии DLL, которые устанавливаются программными продуктами Microsoft.

        Разработка DLL

        В этом разделе описываются проблемы и требования, которые следует учитывать при разработке собственных библиотек DLL.

        Типы DLL

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

        Динамическое связывание во время загрузки

        При динамическом связывании во время загрузки приложение делает явные вызовы экспортированных функций DLL, таких как локальные функции. Чтобы использовать динамическое связывание во время загрузки, предоставьте файл заголовка (.h) и файл библиотеки импорта (.lib) при компиляции и связывании приложения. Когда вы сделаете это, компоновщик предоставит системе информацию, необходимую для загрузки библиотеки DLL и определения местоположения функций экспортированной библиотеки DLL во время загрузки.

        Динамическое связывание во время выполнения

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

        В следующем списке описаны критерии приложения, когда следует использовать динамическую компоновку во время загрузки и когда использовать динамическую компоновку во время выполнения:

        Если важна начальная производительность приложения при запуске, следует использовать динамическую компоновку во время выполнения.

        При динамическом связывании во время загрузки экспортированные функции DLL аналогичны локальным функциям. Это упрощает вызов этих функций.

        При динамической компоновке во время выполнения приложение может разветвляться для загрузки различных модулей по мере необходимости. Это важно при разработке многоязычных версий.

        Точка входа в DLL

        При создании библиотеки DLL можно дополнительно указать функцию точки входа. Функция точки входа вызывается, когда процессы или потоки присоединяются к библиотеке DLL или отсоединяются от нее. Вы можете использовать функцию точки входа для инициализации структур данных или для уничтожения структур данных в соответствии с требованиями DLL. Кроме того, если приложение является многопоточным, вы можете использовать локальное хранилище потока (TLS) для выделения памяти, которая является частной для каждого потока в функции точки входа. Следующий код является примером функции точки входа DLL.

        Если функция точки входа возвращает значение FALSE, приложение не запустится, если вы используете динамическую компоновку во время загрузки. Если вы используете динамическую компоновку во время выполнения, не будет загружаться только отдельная библиотека DLL.

        Функция точки входа должна выполнять только простые задачи инициализации и не должна вызывать какие-либо другие функции загрузки или завершения DLL. Например, в функции точки входа не следует прямо или косвенно вызывать функцию LoadLibrary или функцию LoadLibraryEx. Кроме того, не следует вызывать функцию FreeLibrary, когда процесс завершается.

        В многопоточных приложениях убедитесь, что доступ к глобальным данным DLL синхронизирован (потокобезопасный), чтобы избежать возможного повреждения данных. Для этого используйте TLS для предоставления уникальных данных для каждого потока.

        Экспорт функций DLL

        Чтобы экспортировать функции DLL, можно либо добавить ключевое слово функции к экспортируемым функциям DLL, либо создать файл определения модуля (.def), в котором перечислены экспортированные функции DLL.

        Чтобы использовать ключевое слово функции, вы должны объявить каждую функцию, которую хотите экспортировать, следующим ключевым словом:
        __declspec(dllexport)

        Чтобы использовать экспортированные функции DLL в приложении, необходимо объявить каждую функцию, которую вы хотите импортировать, с помощью следующего ключевого слова: __declspec(dllimport)

        Как правило, вы должны использовать один заголовочный файл с оператором определения и оператором ifdef для разделения оператора экспорта и оператора импорта.

        Вы также можете использовать файл определения модуля для объявления экспортируемых функций DLL. Когда вы используете файл определения модуля, вам не нужно добавлять ключевое слово function к экспортируемым функциям DLL. В файле определения модуля вы объявляете инструкцию LIBRARY и инструкцию EXPORTS для DLL. Следующий код является примером файла определения.

        Пример библиотеки DLL и приложения

        В Visual C++ 6.0 можно создать библиотеку DLL, выбрав тип проекта Win32 Dynamic-Link Library или тип проекта MFC AppWizard (dll).

        Следующий код является примером библиотеки DLL, созданной в Visual C++ с использованием типа проекта Win32 Dynamic-Link Library.

        Следующий код является примером проекта приложения Win32, который вызывает экспортированную функцию DLL в библиотеке DLL SampleDLL.

        При динамическом связывании во время загрузки необходимо связать библиотеку импорта SampleDLL.lib, которая создается при сборке проекта SampleDLL.

        При динамической компоновке во время выполнения вы используете код, аналогичный приведенному ниже, для вызова экспортированной функции DLL SampleDLL.dll.

        При компиляции и компоновке приложения SampleDLL операционная система Windows ищет DLL-библиотеку SampleDLL в следующих местах в указанном порядке:

        Папка приложения

        Текущая папка

        Системная папка Windows

        Функция GetSystemDirectory возвращает путь к системной папке Windows.

        Папка Windows

        Функция GetWindowsDirectory возвращает путь к папке Windows.

        Файл сборки содержит манифест сборки, метаданные типов, код MSIL и другие ресурсы. Манифест сборки содержит метаданные сборки, содержащие всю информацию, необходимую для того, чтобы сборка имела самоописание. В манифест сборки включается следующая информация:

        • Название сборки
        • Информация о версии
        • Информация о культуре
        • Информация о сильном имени
        • Список файлов
        • Введите справочную информацию.
        • Информация о ссылочной и зависимой сборке

        Код MSIL, содержащийся в сборке, не может выполняться напрямую. Вместо этого выполнение кода MSIL управляется через среду CLR. По умолчанию при создании сборки она является частной для приложения. Чтобы создать общую сборку, необходимо присвоить сборке строгое имя, а затем опубликовать сборку в глобальном кэше сборок.

        В следующем списке описаны некоторые функции сборок по сравнению с функциями библиотек DLL Win32:

        При создании сборки вся информация, необходимая среде CLR для запуска сборки, содержится в манифесте сборки. Манифест сборки содержит список зависимых сборок. Таким образом, CLR может поддерживать согласованный набор сборок, используемых в приложении. В библиотеках DLL Win32 невозможно поддерживать согласованность между набором библиотек DLL, используемых в приложении, при использовании общих библиотек DLL.

        В манифесте сборки информация о версии записывается и применяется средой CLR. Кроме того, политики версий позволяют принудительно применять использование для конкретной версии. В библиотеках DLL Win32 управление версиями не может быть принудительно реализовано операционной системой. Вы должны убедиться, что библиотеки DLL обратно совместимы.

        Сборки поддерживают параллельное развертывание. Одно приложение может использовать одну версию сборки, а другое приложение может использовать другую версию сборки. Начиная с Windows 2000, параллельное развертывание поддерживается путем размещения библиотек DLL в папке приложения. Кроме того, защита файлов Windows предотвращает перезапись или замену системных библиотек DLL неавторизованным агентом.

        Самозащита и изоляция

        Приложение, разработанное с использованием сборки, может быть автономным и изолированным от других приложений, работающих на компьютере. Эта функция помогает создавать установки с нулевым воздействием.

        Сборка запускается с разрешениями безопасности, указанными в манифесте сборки и контролируемыми средой CLR.

        Система может содержать несколько версий одной библиотеки динамической компоновки (DLL). Приложения могут управлять расположением, из которого загружается библиотека DLL, указывая полный путь или используя другой механизм, например манифест. Если эти методы не используются, система ищет DLL во время загрузки, как описано в этом разделе.

        Факторы, влияющие на поиск

        Следующие факторы влияют на поиск системой DLL:

        • Если библиотека DLL с таким же именем модуля уже загружена в память, система проверяет только перенаправление и манифест, прежде чем разрешить загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
        • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются) вместо поиска DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.
        • Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это справедливо даже в том случае, если первая библиотека DLL была загружена с указанием полного пути.

        Порядок поиска приложений UWP

        Когда приложение UWP для Windows 10 (или приложение Магазина для Windows 8.x) загружает упакованный модуль, вызывая функцию LoadPackagedLibrary, библиотека DLL должна находиться в графе зависимостей пакетов процесса. Дополнительные сведения см. в разделе LoadPackagedLibrary. Когда приложение UWP загружает модуль другими способами и не указывает полный путь, система ищет библиотеку DLL и ее зависимости во время загрузки, как описано в этом разделе.

        Прежде чем система начнет поиск DLL, она проверяет следующее:

        • Если библиотека DLL с таким же именем модуля уже загружена в память, система использует загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
        • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются). Система не ищет DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

        Если система должна искать модуль или его зависимости, она всегда использует порядок поиска для приложений UWP, даже если зависимость не является кодом приложения UWP.

        Стандартный порядок поиска для приложений UWP

        Если модуль еще не загружен или не находится в списке известных DLL, система ищет эти местоположения в следующем порядке:

          Граф зависимостей пакетов процесса. Это пакет приложения плюс любые зависимости, указанные как

        Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это верно, даже если первая DLL была загружена с указанием полного пути.

        Альтернативный порядок поиска для приложений UWP

        Если модуль изменяет стандартный порядок поиска, вызывая функцию LoadLibraryEx с параметром LOAD_WITH_ALTERED_SEARCH_PATH, система ищет каталог, из которого был загружен указанный модуль, а не каталог вызывающего процесса. Система ищет эти местоположения в следующем порядке:

          Граф зависимостей пакетов процесса. Это пакет приложения плюс любые зависимости, указанные как

        Порядок поиска для настольных приложений

        Настольные приложения могут управлять расположением, из которого загружается библиотека DLL, путем указания полного пути, использования перенаправления библиотеки DLL или манифеста. Если ни один из этих методов не используется, система ищет DLL во время загрузки, как описано в этом разделе.

        Прежде чем система начнет поиск DLL, она проверяет следующее:

        • Если библиотека DLL с таким же именем модуля уже загружена в память, система использует загруженную библиотеку DLL, независимо от того, в каком каталоге она находится. Система не выполняет поиск библиотеки DLL.
        • Если библиотека DLL находится в списке известных библиотек DLL для версии Windows, в которой работает приложение, система использует свою копию известной библиотеки DLL (и зависимые от нее библиотеки DLL, если таковые имеются). Система не ищет DLL. Список известных библиотек DLL в текущей системе см. в следующем разделе реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

        Если библиотека DLL имеет зависимости, система ищет зависимые библиотеки DLL, как если бы они были загружены только с именами модулей. Это верно, даже если первая DLL была загружена с указанием полного пути.

        Если злоумышленник получает контроль над одним из каталогов, в которых выполняется поиск, он может поместить в этот каталог вредоносную копию библиотеки DLL. Способы предотвращения таких атак см. в разделе Безопасность библиотеки Dynamic-Link.

        Стандартный порядок поиска для настольных приложений

        Стандартный порядок поиска DLL, используемый системой, зависит от того, включен или отключен режим безопасного поиска DLL. В режиме безопасного поиска DLL текущий каталог пользователя размещается позже в порядке поиска.

        Режим безопасного поиска DLL включен по умолчанию. Чтобы отключить эту функцию, создайте значение реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode и установите для него значение 0. Вызов функции SetDllDirectory эффективно отключает SafeDllSearchMode, пока указанный каталог находится в пути поиска, и изменяет порядок поиска, как описано. в этой теме.

        Если SafeDllSearchMode включен, порядок поиска следующий:

        1. Каталог, из которого загружено приложение.
        2. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
        3. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется.
        4. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        5. Текущий каталог.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Если SafeDllSearchMode отключен, порядок поиска следующий:

        1. Каталог, из которого загружено приложение.
        2. Текущий каталог.
        3. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
        4. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется.
        5. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Альтернативный порядок поиска для настольных приложений

        Стандартный порядок поиска, используемый системой, можно изменить, вызвав функцию LoadLibraryEx с параметром LOAD_WITH_ALTERED_SEARCH_PATH. Стандартный порядок поиска также можно изменить, вызвав функцию SetDllDirectory.

        На стандартный порядок поиска процесса также влияет вызов функции SetDllDirectory в родительском процессе перед запуском текущего процесса.

        Если вы укажете альтернативную стратегию поиска, ее поведение будет продолжаться до тех пор, пока не будут обнаружены все связанные исполняемые модули. После того как система начнет обрабатывать процедуры инициализации DLL, система вернется к стандартной стратегии поиска.

        Функция LoadLibraryEx поддерживает альтернативный порядок поиска, если в вызове указано LOAD_WITH_ALTERED_SEARCH_PATH, а параметр lpFileName указывает абсолютный путь.

        Обратите внимание, что стандартная стратегия поиска и альтернативная стратегия поиска, указанные LoadLibraryEx с помощью LOAD_WITH_ALTERED_SEARCH_PATH, отличаются только одним: стандартный поиск начинается в каталоге вызывающего приложения, а альтернативный поиск начинается в каталоге исполняемого модуля, которым является LoadLibraryEx. загрузка.

        Если SafeDllSearchMode включен, альтернативный порядок поиска выглядит следующим образом:

        1. Каталог, указанный параметром lpFileName.
        2. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
        3. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется.
        4. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        5. Текущий каталог.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Если SafeDllSearchMode отключен, альтернативный порядок поиска следующий:

        1. Каталог, указанный параметром lpFileName.
        2. Текущий каталог.
        3. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу.
        4. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется.
        5. Каталог Windows. Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Функция SetDllDirectory поддерживает альтернативный порядок поиска, если параметр lpPathName указывает путь. Альтернативный порядок поиска следующий:

        1. Каталог, из которого загружено приложение.
        2. Каталог, указанный параметром lpPathName в SetDllDirectory.
        3. Системный каталог. Используйте функцию GetSystemDirectory, чтобы получить путь к этому каталогу. Имя этого каталога — System32.
        4. 16-битный системный каталог. Нет функции, которая получает путь к этому каталогу, но он ищется. Имя этого каталога — System.
        5. Каталог Windows.Используйте функцию GetWindowsDirectory, чтобы получить путь к этому каталогу.
        6. Каталоги, указанные в переменной среды PATH. Обратите внимание, что сюда не входит путь для каждого приложения, указанный в разделе реестра App Paths. Ключ App Paths не используется при вычислении пути поиска DLL.

        Если параметр lpPathName является пустой строкой, вызов удаляет текущий каталог из порядка поиска.

        SetDllDirectory эффективно отключает безопасный режим поиска DLL, пока указанный каталог находится в пути поиска. Чтобы восстановить безопасный режим поиска DLL на основе значения реестра SafeDllSearchMode и восстановить текущий каталог в соответствии с порядком поиска, вызовите SetDllDirectory с lpPathName равным NULL.

        Порядок поиска с использованием флагов LOAD_LIBRARY_SEARCH

        Приложение может указать порядок поиска, используя один или несколько флагов LOAD_LIBRARY_SEARCH с функцией LoadLibraryEx. Приложение также может использовать флаги LOAD_LIBRARY_SEARCH с функцией SetDefaultDllDirectories, чтобы установить порядок поиска DLL для процесса. Приложение может указать дополнительные каталоги для порядка поиска DLL процесса с помощью функций AddDllDirectory или SetDllDirectory.

        Каталоги, в которых выполняется поиск, зависят от флагов, указанных с помощью SetDefaultDllDirectories или LoadLibraryEx. Если используется более одного флага, соответствующие каталоги ищутся в следующем порядке:

        1. Каталог, содержащий библиотеку DLL (LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR). В этом каталоге ищутся только зависимости загружаемой библиотеки DLL.
        2. Каталог приложения (LOAD_LIBRARY_SEARCH_APPLICATION_DIR).
        3. Пути, явно добавленные с помощью функции AddDllDirectory (LOAD_LIBRARY_SEARCH_USER_DIRS) или функции SetDllDirectory. Если добавлено более одного пути, порядок поиска путей не указан.
        4. Системный каталог (LOAD_LIBRARY_SEARCH_SYSTEM32).

        Если приложение не вызывает LoadLibraryEx с какими-либо флагами LOAD_LIBRARY_SEARCH и не устанавливает порядок поиска DLL для процесса, система ищет библиотеки DLL, используя либо стандартный порядок поиска, либо альтернативный порядок поиска.

        27 ноября 2015 г. Стефан Кантак связался с Rapid7, чтобы сообщить об уязвимости в инструменте Rapid7 ScanNow. Rapid7 серьезно относится к вопросам безопасности, и это не стало исключением. В сочетании с ранее существовавшей компрометацией или другими уязвимостями и при отсутствии достаточных мер по смягчению последствий система с ScanNow может позволить злоумышленнику выполнить код по своему выбору, что приведет к различным уровням дополнительной компрометации. Чтобы защитить небольшое сообщество пользователей, которые все еще могут использовать ScanNow, Rapid7 принял решение удалить ScanNow и рекомендует всем затронутым пользователям удалить ScanNow из любой системы, в которой он все еще установлен.

        Сведения об уязвимости

        ScanNow от Rapid7 – это набор из нескольких отдельных автономных исполняемых файлов, созданных за последние несколько лет и предназначенных для того, чтобы дать пользователям и сообществу возможность быстро проверить себя на наличие уязвимостей более высокого профиля, которые за это время попали в заголовки различных уровней:< /p>

        Уязвимость, о которой сообщил Rapid7 Стефан, представляет собой общую уязвимость, наиболее официальное название которой — "Перехват порядка поиска DLL", но ее также называют боковой загрузкой DLL, предварительной загрузкой DLL, установкой двоичных файлов, бомбардировкой бинарных ковров или другими подобными названиями. Перехват порядка поиска DLL стал более популярным в 2010 году, когда компания ACROS Security опубликовала здесь обширную информацию о нем, и за эти годы он затронул сотни продуктов и продолжает это делать.

        Уязвимость этого класса возникает, когда приложение Windows пытается загрузить библиотеку DLL или другую библиотеку, используя неполный путь поиска. Если путь поиска библиотеки DLL недостаточно квалифицирован, Windows имеет предопределенный список мест, в которых она будет проверять наличие рассматриваемой библиотеки. В этот список включены места, которые могут быть ненадежными или небезопасными, и если рассматриваемая библиотека находится в одном из этих мест, возможно, загруженная библиотека содержит вредоносный код, который может привести к выполнению произвольного кода при запуске целевого исполняемого файла. .

        Изучив этот отчет об уязвимости, Rapid7 обнаружил, что ни один из кодов, написанных Rapid7 для ScanNow, не использует какой-либо потенциально уязвимый код Windows API для загрузки библиотек или выполнения процессов, не говоря уже о том, что уязвимость может быть использована в любой сценарий. Вместо этого уязвимость присутствует в ScanNow из-за способа упаковки и распространения ScanNow, часть которого включает 7-zip. 7-zip можно использовать для нескольких целей.В случае ScanNow он используется для создания автономного исполняемого файла самораспаковывающегося архива (SFX), который в основном представляет собой просто исполняемый файл, который при запуске распаковывает фактический исполняемый файл ScanNow вместе со всеми необходимыми ему ресурсами, а затем запускает сам ScanNow. . Основная причина, по-видимому, та же, что затронула Mozilla Foundation в 2012 году после публикации для полного раскрытия. Похоже, что эта уязвимость остается неустраненной, и в другом информационном сообщении, опубликованном Стефаном вскоре после того, как он связался с нами, указывается, что в дополнение к самой уязвимости 7-zip для перехвата порядка поиска DLL уязвимы все самораспаковывающиеся архивы, созданные с помощью 7-zip.

        В настоящее время Rapid7 назначил вектор CVSS (AV:N/AC:H/Au:N/C:C/I:C/A:C) с соответствующим оценка 7,6 для этой уязвимости, но мы также понимаем, что сведения о реальном риске, связанном с этой уязвимостью, сложны и не могут быть легко отражены в векторе CVSS.

        Сценарии эксплуатации

        При обсуждении уязвимостей, связанных с перехватом порядка поиска DLL, вопрос о том, можно ли их использовать удаленно, почти неизбежно поднимается и быстро отвлекает от рассматриваемой проблемы из-за реакции, которую она обычно вызывает. Хотя мы считаем, что называть это уязвимостью, которую можно использовать удаленно, немного неточно, важно понимать, что у этой уязвимости есть характеристики «удаленного подобия», как показано ниже.

        Использование уязвимости перехвата порядка поиска DLL в Windows не так уж сильно отличается от использования LD_PRELOAD и аналогичных уязвимостей в мире UNIX, а именно: для ее использования каким-то образом должна быть размещена вредоносная библиотека в местоположении, которое будет искать целевое приложение до того, как правильная, ожидаемая библиотека будет найдена и загружена уязвимым приложением. Это происходит разными способами, в том числе:

        • Вредоносный _local_user или процесс, который может записывать произвольное содержимое в файл, расположенный в каталоге, который будет выполняться при попытке найти библиотеку DLL для загрузки целевым приложением. Это могло произойти из-за другой ранее использованной и несвязанной уязвимости.
        • Вредоносные библиотеки DLL были каким-то образом доставлены в недостаточно защищенные каталоги с использованием чего-то вроде уязвимости загрузки с диска.
        • Социальная инженерия.

        Кроме того, в целевой системе и приложении не должно быть мер по усилению защиты, предназначенных для смягчения или предотвращения использования уязвимости этого типа.

        В качестве простого примера того, как это можно использовать, я использовал следующий код, который просто запускает калькулятор Windows, calc.exe, всякий раз, когда загружается эта DLL:

        Затем свяжите и скомпилируйте как обычно. В этом случае я использовал mingw:

        Затем я копирую вредоносную DLL (их может быть несколько) в каталог, где живет ScanNow, или в каталог, из которого осуществляется вызов ScanNow. В данном конкретном случае я просто поместил образец вредоносной DLL в папку «Загрузки»:


        Затем, при выполнении ScanNow либо с неполным путем в разделе «Загрузки», либо с полным путем, вы увидите, что был выполнен calc, что доказывает наличие этой уязвимости:


        Очевидно, что заключительная часть использования этой уязвимости заключается в том, чтобы заставить целевую систему каким-то образом запустить ScanNow в уязвимой среде, что может произойти с помощью социальной инженерии, использования другой, возможно, не связанной с этим уязвимости или просто везения.

        Исправление и смягчение последствий

        Характер того, как ScanNow создается, распространяется и используется, в сочетании с особенностями, связанными с уязвимостью, ее использованием и способами смягчения, усложнил реакцию Rapid7 на эту уязвимость.

        Рекомендации по безопасности Microsoft 2269637 не особенно важны в данном конкретном случае. По сути, это ответ Microsoft на то, что этот класс уязвимостей впервые действительно стал настоящим лесным пожаром в 2010 году, и в нем перечислены все уязвимости на сегодняшний день в продуктах Microsoft, относящихся к тому же базовому классу (DLL Search Order Hijacking), из которых было 28 советов MS и несколько общих статей MS KnowledgeBase или TechNet с момента его первоначального написания в 2010 году. Это довольно много. Однако только решения в двух из них потенциально актуальны при обсуждении этой уязвимости, и, как я описываю ниже, большинство из них также оказались проблематичными.

        Безопасность библиотеки Dynamic-Link (Windows) не очень актуальна в нашем случае, поскольку мы не контролируем код, выполняющий небезопасные вызовы. В противном случае это был бы прекрасный вариант.

        Порядок поиска в библиотеке Dynamic-Link (Windows) звучит так, как будто он должен работать. В основном это помогает, когда приложение не соответствует предыдущей рекомендации, и блокировка должна происходить на клиенте, выполняющем приложение, а не при его сборке. Мы обнаружили, что это не может предотвратить использование этой уязвимости (на самом деле скриншоты выше были сделаны в системе, настроенной так, как это предлагается в этой ссылке). Почему в настоящее время неизвестно и может стать областью будущих исследований.

        CAPEC – CAPEC-471: Перехват порядка поиска DLL (версия 2.8) хорошо объясняет, что представляет собой уязвимость, связанная с перехватом порядка поиска DLL, как она используется, и предлагает CAPEC – CAPEC-159: перенаправление доступа к библиотекам (версия 2.8) в качестве решения. Это решение фактически дает 3 варианта. Первые два по существу идентичны двум предыдущим пунктам (модификации исходного кода, которые, опять же, неприменимы в нашем случае, и усиление защиты на стороне клиента, которое в данном случае оказалось неэффективным). Третье и последнее предложение состоит в том, чтобы подписать системные библиотеки DLL, ответственность за которые в данном случае лежит на Microsoft (правильно?), и будет применимо только в том случае, если затронутое приложение небезопасно загружает только системные библиотеки DLL (в отличие от несистемных библиотек DLL). В случае со ScanNow и наш, и наш POC Стефана используют UXTheme.dll, которая обычно существует как uxtheme.dll в большинстве операционных систем Windows, начиная с XP, в обычных местах, скрытых в C:\Windows. Предполагается, что если бы было доступно решение для подписи, уязвимость была бы в некоторой степени смягчена, но подписание библиотек DLL — это относительно простой процесс, и есть способы попытаться обойти подобные проверки подписи. Другими словами, подписание помогает, но, возможно, не тогда, когда вы сталкиваетесь со сверхрешительным противником. Кроме того, POC Стефана, который он использовал в течение нескольких лет в сообществе безопасности, называемый дозорным, подписан, и сообщалось, что существуют другие возможности для использования этого класса уязвимости в ScanNow помимо UXTheme.dll, которые могут быть или не быть подписано по умолчанию.

        CAPEC – CAPEC-159: перенаправление доступа к библиотекам (версия 2.8) — это похожая, но немного другая уязвимость, и, к сожалению, ее решения имитируют то, что было предложено выше другими, которые оказались неактуальными или неэффективными по разным причинам.< /p>

        И CWE — CWE-426: Ненадежный путь поиска (2.9), и CWE — CWE-427: Неконтролируемый элемент пути поиска (2.9) охватывают уязвимости и решения, практически идентичные всему вышеперечисленному, с вышеупомянутыми недостатками.

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

        Параметры групповой политики UAC и параметры ключа реестра показывают, что существуют некоторые параметры, которые существуют в системах с поддержкой UAC для автоматического управления правами администратора установщиками и, когда отключены, требуют, чтобы пользователь мог успешно пройти аутентификацию как администратора, прежде чем позволить установщику использовать административные привилегии. Когда этот параметр отключен, все, что он делает, — это предотвращает немедленный и легкий переход от использования уязвимости перехвата порядка поиска DLL в программе установки к получению административных привилегий. Другими словами, уязвимость все еще использовалась, но текущий ущерб был остановлен до дальнейшего повышения привилегий. Хотя этот параметр отключен во всех корпоративных операционных системах Windows, в системах домашних пользователей Windows этот параметр включен по умолчанию, и впоследствии существует риск того, что это превратится в более быструю EOP.

        Короче говоря, существует очень мало рабочих вариантов возникновения этой уязвимости в ScanNow, и похоже, что это затруднительное положение, с которым придется столкнуться многим, когда они столкнутся с уязвимостью перехвата порядка поиска DLL. Обе эти области могут созреть для будущих исследований.

        Всем, кто загрузил ScanNow, рекомендуется найти и удалить уязвимые исполняемые файлы. Для всех пользователей, которым все еще нужен ScanNow, и Metasploit, и Nexpose лучше охватывают уязвимости, которые ранее закрывал ScanNow. Для всех, кто регистрировался при загрузке ScanNow в течение многих лет, Rapid7 также попытается связаться с этими пользователями, чтобы сообщить им о ситуации.

        Rapid7 еще раз благодарит Стефана Кантака за ответственное раскрытие этой уязвимости.

        Читайте также: