Скорее я нахожусь с другой стороны этого герметичного люка: запись в каталог приложения

Это перевод It rather involved being on the other side of this airtight hatchway: Writing to the application directory. Автор: Реймонд Чен.

Мы получили один отчёт о найденной уязвимости безопасности, который выглядел примерно так:

В компоненте X есть уязвимость безопасности. Он загружает shell32.dll из текущего каталога. Иными словами, он уязвим для атаки на текущий каталог. Вот пример, иллюстрирующий проблему: скопируйте изменённую shell32.dll в текущий каталог и запустите программу. Заметьте, что будет запущена изменённая shell32.dll вместо системной.

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

Предположим, что программа размещается в каталоге C:\sample\sample.exe.

1. Установим текущий каталог = каталогу приложения:

   cd /d C:\sample
   copy \\rogue\server\shell32.dll
   c:\sample\sample.exe

   В этом случае атака успешна.
2. Установим текущий каталог в любой другой каталог:

   cd /d %USERPROFILE%
   copy \\rogue\server\shell32.dll
   c:\sample\sample.exe

   В этом случае атака неудачна.
3. Запустим приложение из Проводника Windows (Windows Explorer):

   copy \\rogue\server\shell32.dll

   Дважды-щёлкаем по sample.exe в Проводнике.
   В этом случае атака успешна.

Давайте сначала посмотрим на случай 3. Какой каталог будет текущим в этом случае? Когда вы запускаете программу из Проводника, он запускает программу, указывая её каталог в качестве текущего (прим. пер.: см. также). Иными словами, случай 3 эквивалентен случаю 1. Окей, одним меньше.

А если мы посмотрим на случай два, то увидим, что эта атака не является атакой на текущий каталог, потому что атака была неудачна, хотя изменённая shell32.dll в текущем каталоге была.

На самом деле мы видим атаку на каталог приложения.

Вспомните, что каталог приложения просматривается раньше системного каталога. Поэтому вы легко можете ввести перегрузку системных библиотек, разместив одноимённый файл в каталоге своего приложения (прим. пер.: за исключением DLL из списка "известных"). Это поведение - часть принципа "каталог - это пакет". Если вы размещаете некую DLL в каталоге приложения, то подразумевается, что вы хотите использовать именно её, даже если какая-то будущая версия Windows добавит системную DLL с таким же именем.

Автор отчёта признал, что, да, имеет место именно атака на каталог приложения. И привёл пример, почему это серьёзная проблема:

Если я скопирую изменённую копию shell32.dll в каталог C:\Program Files\Microsoft Office\Office12, то я смогу внедрить код во все приложения Microsoft Office.

Если бы отчёт описывал атаку на текущий каталог, то атакующему нужно было бы поместить файл shell32.dll в каталог со, скажем, документом Excel, а не в каталог с Excel.exe.

И как раз в этот момент вы наталкиваетесь на герметичный люк: обычные пользователи, запускающие Office, не имеют прав на запись в каталог C:\Program Files\Microsoft Office\Office12. Только администраторы машины имеют на это право. А если у вас уже есть привилегии администратора, то вы и так владеете машиной. Нет нужды искать обходные пути, вы и так можете выполнить любые действия напрямую. То, что администратор может сделать с машиной что угодно - это не уязвимость безопасности.

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

Убедитесь, что вы контролируете к нему доступ! Если вы сделаете каталог приложения доступным для записи для всех, то этим вы "разгерметизируете люк". Это одна из причин, почему Microsoft требует, чтобы программы устанавливались бы в каталог Program Files по умолчанию: описатель безопасности на подкаталоги Program Files не разрешает запись обычным пользователям. Эти каталоги по умолчанию защищены. (прим. пер.: вторая причина)

Нам приходит множество аналогичных отчётов о найденных "проблемах с безопасностью" - и почти все они часто ошибочно характеризуются как атаки на текущий каталог. Вот типичный отчёт:

В LITWARE.EXE есть уязвимость внедрения DLL. Поместите "левую" SHELL32.DLL в каталог LITWARE.EXE. Когда стартует LITWARE.EXE, она загружает DLL из текущего каталога, что приводит к успешному внедрению кода.

Автор отчёта перепутал текущий каталог и каталог приложения, потому что он не подумал, что эти каталоги могут отличаться.

C:\> mkdir C:\test
C:\> cd C:\test
C:\test> copy \\trusted\server\LITWARE.EXE
C:\test> copy \\rogue\server\SHELL32.DLL
C:\test> LITWARE

-- заметьте, что загружается "левая" DLL
-- доказана успешная атака на текущий каталог

Но они никогда не пробуют сделать так:

C:\> mkdir C:\test
C:\> cd C:\test
C:\test> copy \\trusted\server\LITWARE.EXE
C:\> mkdir C:\test2
C:\> cd C:\test2
C:\test2> copy \\rogue\server\SHELL32.DLL
C:\test2> ..\test\LITWARE

-- заметьте, что "левая" DLL не загружается

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

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

P.S. В частности, это означает, что нам нужно проверить все версии программы LitWare на всех версиях Windows, в любых комбинациях - просто чтобы убедиться, что все возможности были проверены. Конечно же, обычно это будет ложной тревогой, но кто знает. Может есть что-то во взаимодействии между LitWare 5.2 SP2 и Windows XP SP3, что приводит к вызову какой-то новой ветки кода, которая действительно пытается загрузить shell32.dll из текущего каталога - и именно эту комбинацию пытается сообщить нам автор отчёта.