Избегайте приложения иметь доступ к операциям на диске

Question

Давайте догадаемся, в моем приложении я разрешаю загружать DLL с LoadLibrary WIN32. Поскольку я не знаю код этой DLL, это может быть вредоносным. Итак, мой вопрос, есть ли какой-нибудь способ сказать Windows, чтобы применить некоторые ограничения к этой DLL (например, доступ к диску, чтение паролей или другие потенциально опасные данные чтения / записи доступа)?

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

Существует ли какой-либо подобный механизм, который я мог бы использовать?

ex1 : RestrictAccess (GetProcAdress (...), размер); // по коду доступа к памяти

ex2 : thread1.loadLibrary (файл); RestrictAccess (thread1); // по потоку доступа

и т.д ...

Answer 1

Вы можете прочитать имена из файла DLL. Таким образом, вы можете быть уверены, с какими другими DLL он связан и какую внешнюю функцию (например, Windows API) он использует. Вы можете создать белый список, чтобы позволить вашим функциям вызываться только из этой библиотеки DLL, таким образом, вам нужно создать функцию-оболочку для всего, что плагин может получить легальный доступ.

Answer 2

Типичное решение состоит в том, чтобы разрешить плагины только на скомпилированном языке или скомпилированном байт-коде, который может быть помещен в «песочницу» (например, Lua). Некоторые операционные системы налагают такие ограничения (например, iOS и Android), но я не верю, что вы найдете такие функции при загрузке встроенной библиотеки Windows DLL.

Answer 3

Привилегии могут быть увеличены для каждого потока, используя олицетворение, но никогда не уменьшаться (поскольку недоверенный код всегда может выполнять RevertToSelf).

Минимальная единица для более низких привилегий - процесс.И да, для этого есть API: CreateProcessAsUser.Вы можете использовать каналы для передачи данных в / из ненадежного процесса.

Или вы можете использовать DCOM для вызова методов объекта в DLL.Вы можете указать учетные данные, а затем ОС выполнит работу по настройке вспомогательного процесса с этими учетными данными и перенаправлению данных туда и обратно.

Answer 4

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

Что IE делает в защищенном режиме (в Vista и Windows 7), так это загружает плагины в отдельный процесс с низким уровнем целостности . Процессы, работающие в режиме низкой целостности, имеют меньший доступ к системным ресурсам и более изолированы от процессов с более высоким уровнем целостности. Вы также можете настроить ACL для таких объектов, как объекты файловой системы и ключи реестра, которые контролируют, могут ли процессы с низким уровнем целостности получать к ним доступ. Это ограничивает количество урона, которое они могут нанести. Это форма песочницы или (в зависимости от того, насколько строго вы ее определяете) виртуализации.

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

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

Еще один подход - перехватить все вызовы API OS, которые вы хотите ограничить. Для этого есть библиотеки , но этот метод основан на небольшом взломе ОС, который может сломаться при любом обновлении. Идея состоит в том, чтобы создать процесс с некоторым вашим кодом, который устанавливает хук для каждого API, который вы хотите ограничить, а затем загружает ненадежный код и выполняет его. Если DLL вызывает перехваченный API (например, CreateFile), вместо этого будет вызываться ваш код, и он может решить, возвратить ли ошибку или передать вызов в реальный API OS. Это сложно, потому что количество API, которые вы должны подключить, может быть огромным. Кроме того, если DLL знает, что этот метод используется, есть вещи, которые она может сделать, чтобы подорвать ее.

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

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