Это перевод Your debugging code can be a security vulnerability: Loading optional debugging DLLs without a full path. Автор: Реймонд Чен.

Запомните: плохих парней не заботит, если вы добавили код лишь для целей отладки. Если есть код — они его атакуют.

Посмотрите на такой код:

type
  TDocLoadingProc = procedure(Stream: TStream);

var
  OnDocLoading: TDocLoadingProc;

procedure LoadDebuggingHooks;
var
  hmodDebug: HMODULE;
begin
  hmodDebug := LoadLibrary('DebugHooks.dll');
  if hmodDebug = 0 then
    Exit;
  OnDocLoading := GetProcAddress(hmodDebug, 'OnDocLoading');
end;

function LoadDocument({...}): HRESULT;
begin
  // ...
  if Assigned(OnDocLoading) 
    // Дадим отладочной ловушке изменить документ перед загрузкой
    OnDocLoading(DocStream);
  // ...
end;

Если вы хотите отлаживать вашу программу, вы копируете DebugHooks.dll в папку приложения. Код выше ищет эту DLL и загружает её, если она есть. Для примера я включил код одной из возможных ловушек из этой отладочной DLL. Идея примера (и это просто пример, так что давайте не будем обсуждать, хороший ли это пример) состоит в том, что непосредственно перед загрузкой документа мы вызываем функцию OnDocLoading. Эта функция может обернуть переданный ей поток в другой поток, так что содержимое потока можно логгировать при его чтении — в попытке локализовать на чём стопорится загрузка документа. Или её можно использовать для инъекции ошибок ввода-вывода с целью тестирования. В общем, используйте своё воображение.

Но этот отладочный код также содержит уязвимость.

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

1. Каталог приложения;
2. Каталог system32;
3. Каталог system;
4. Каталог Windows;
5. Текущий каталог;
6. Пути из PATH.

Когда вы отлаживаете программу, вы копируете DebugHooks.dll в папку приложения, откуда она и загружается (шаг 1 в списке выше). Но если вы не отлаживаете свою программу, то шаг 1 пропускается, и поиск продолжается дальше. DLL не будет найдена на шаге 2, 3 и 4, и в итоге мы достигаем шага 5: текущего каталога.

И теперь вас хакнули.

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

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

Когда вы дважды-щёлкаете по файлу, Проводник устанавливает текущий каталог для приложения-обработчика этого файла равным каталогу, в котором расположен этот файл. Это необходимо для правильной работы приложений, которые ищут в текущем каталоге вспомогательные файлы. Например, представьте гипотетическое приложение LitWare Writer, ассоциированное с файлами *.LIT. Документ приложения LitWare Writer, представленный файлом ABC.LIT — это просто представитель семейства файлов: ABC.LIT (главный документ), ABC.LTC (индекс документа и содержание), ABC.LDC (словарь грамматики для документа), ABC.LLT (пользовательский шаблон для документа) и так далее. Когда вы открываете документ C:PROPOSALABC.LIT, LitWare Writer ищет остальные части документа в текущей папке, вместо C:PROPOSAL. Чтобы помочь таким приложениям найти все необходимые файлы, Проводник указывает функции CreateProcess, что текущий каталог для приложения LitWare Writer должен быть равен C:PROPOSAL.

Так, вы можете сказать, что программы вроде этого LitWare Writer (которые ищут файлы в текущей папке вместо папки с главным документом) плохо написаны, и я в этом с вами соглашусь. Однако Windows нужно работать даже с плохо написанными программами (упреждающее ехидное замечание: Windows сама плохо написана). В реальном мире есть слишком много плохо написанных программ, некоторые из которых являются лидерами в своих сегментах (см. выше упреждающий остроумный комментарий), и если Windows перестанет их запускать, люди скажут, что это вина Windows, а не этих программ.

Мне даже не надо закрывать глаза, чтобы представить, как нам присылают баг-отчёт с этим поведением:

«Эта программа отлично работает в MS-DOS, но в Windows она не работает. Тупая Windows».

Клиент не будет счастлив услышать следующий ответ: «Вообще-то, эта программа никогда и не работала верно, ей просто везло все эти X лет. Авторы этой программы никогда не рассматривали случай, если открываемый документ расположен вне текущего каталога. Им это сошло с рук, потому что обычно вы открываете файлы в MS-DOS следующим образом: вы переходите в каталог с документом и потом набираете LWW ABC.LIT. Но если вы выполните в MS-DOS LWW C:PROPOSALABC.LIT, то увидите то же (неверное) поведение программы. Иными словами, это поведение системы — не баг, а дизайн».

Ответ на «Это поведение по проекту» обычно звучит как «Я скажу так, что дизайн, который не даёт мне выполнять мою работу — отстойный дизайн» или кратко: «Нет, это не дизайн, это баг» (вы не верите мне, что такое происходит? Просто почитайте Slashdot).

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

Но сказанное также означает, что если вы запустили программу двойным щелчком по ассоциированному документу, то программа будет удерживать каталог с документом — потому что этот каталог будет текущим. Если только, конечно, сама программа потом не изменит свой текущий каталог.

Бонус-замечание: изначально я написал эту серию заметок более двух лет назад. Но даже тогда я не считал их чем-то удивительным, новаторским или интересным. Но, похоже, некоторые люди вновь открыли это несколько месяцев назад, и вылезли из кожи вон, чтобы присвоить себе лавры первооткрывателей. Это как новое поколение подростков, которые думают, что они изобрели секс. Чисто для протокола: вот некоторые официальные инструкции (и, чтобы расставить все точки над i: это официальные инструкции по атаке на текущий каталог, а не официальные инструкции по сексу).

Историческое замечание: почему вообще есть текущий каталог? Ответ: это идёт со времён CP/M. В CP/M не было PATH. Всё запускалось из текущего каталога. Сегодняшнее состояние вещей — это цепочка из обратных совместимостей.

Читать на сайте автора.

Это перевод For a brief shining moment, DirectX was more popular than another word that ends in x. Автор: Реймонд Чен.

В месяц сразу после выхода DirectX 3 слово «directx» стало самым популярным для поиска на microsoft.com. Само по себе, это не было столь удивительным.

Удивительным было слово на шестом месте: «sex».

Вы знаете, это вводит меня в ступор до сих пор. Кто вообще ищет «sex» на microsoft.com? И что, собственно говоря, они ожидают найти?

Читать на сайте автора.

Это перевод What if two programs did this? Practical exam. Автор: Реймонд Чен.

У клиента, который не читает этот блог, есть следующий вопрос.

У нашего приложения есть требование: оно должно быть поверх всех других окон, даже если показываются окна со стилем topmost. Для этого в наших сообщениях WM_KILLFOCUS и WM_PAINT мы делаем наше окно topmost, а затем вызываем SetWindowPos, чтобы вынести наше окно поверх остальных, и дополнительно мы вызываем SetForegroundWindow — просто на всякий случай.

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

В настоящее время мы пишем DLL, которая установит ловушку на все оконные сообщения и [дальше идёт перечисление ещё более сумасшедших идей, которые не стоят того, чтобы тратить на них время], но сейчас это приводит к вылету других приложений. Мы также рассматриваем возможность установки таймера и вызова SetWindowPos по таймеру, но это кажется недостаточным.

Этот клиент не провёл мысленный эксперимент Что если две программы сделают это?; он просто взял и сделал это! Результат был предсказуем: две программы стали бороться друг с другом. Никто не выиграл, обе проиграли — и особенно досталось пользователю.

Читать на сайте автора.

Это перевод The curse of the current directory. Автор: Реймонд Чен.

Текущий каталог — это и благо и проклятие. Это благо, потому что экономит вам набор текста (путём использования относительных путей). Это проклятие по всем остальным причинам.

Корнем многих зол является то, что в семейство операционных систем Windows NT держит открытым описатель текущего каталога каждого процесса (упреждающий комментарий от Yuhong Bao: семейство систем Windows 95, напротив, не держало описатель открытым, что порождало кучу других проблем, что, впрочем, никак не связано с темой этого поста).

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

Я пытаюсь удалить каталог X, но при попытке его удалить, я получаю сообщение об ошибке: «Процесс не может получить доступ к файлу, поскольку он открыт в другой программе»… После долгих часов, я нашёл виновника: оказывается, каталог X держится программой someapp.exe. Какого чёрта ей вообще надо в моём каталоге? Как мне удалить каталог?

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

Но почти во всех случаях, someapp.exe — просто невинная жертва текущего каталога.

Во-первых, рассмотрим отдельно случай, когда someapp.exe — это explorer.exe. Почему текущий каталог Проводника может быть равен этому каталогу?

Ну, быть может потому, что это ещё одно проклятие текущего каталога, а именно: текущий каталог — один на весь процесс, это глобальная настройка. Если расширение Оболочки решило вызвать SetCurrentDirectory, то этим она поменяла текущий каталог для всего Проводника. И если это расширение не побеспокоилось о том, чтобы вызвать SetCurrentDirectory второй раз для возврата предыдущего текущего каталога, то теперь текущий каталог застрял на этом каталоге.

Заметьте, что даже если расширение оболочки попытается сделать всё правильно, то это может не сработать:

GetCurrentDirectory(Old) // возвращает C:Previous
SetCurrentDirectory(New) // меняет на C:Victim
.. что-то делаем ..
SetCurrentDirectory(Old) // меняем на C:Previous - неудачно?!

Второй вызов SetCurrentDirectory может завершиться неудачей, если, к примеру, каталог C:Previous был удалён или переименован, пока расширение оболочки делало свою работу. Расширение Оболочки не может вернуть текущий каталог, так что оно оставляет C:Victim текущим каталогом, и теперь вы не можете удалить C:Victim, потому что он стал текущим каталогом Проводника.

(Кстати, совсем правильное решение — это вообще не вызывать SetCurrentDirectory, а оперировать абсолютными полными путями. Поскольку текущий каталог — это глобальная настройка процесса, вы не можете гарантировать, что какой-то другой поток не вызовет SetCurrentDirectory в то время, когда вы работаете с относительными именами файлов).

Заметьте, что если сделать текущий каталог настройкой потока (перевод поста), а не процесса, то это также не решит проблему (полностью), потому что текущий каталог потока (если бы такая вещь существовала бы) всё равно держал бы открытым описатель текущего каталога. Но если бы текущий каталог был бы настройкой потока, то, по крайней мере, если бы этот поток был ассоциирован с окном, то вы могли бы закрыть окно и, таким образом, завершить поток — что, в свою очередь, освободило бы открытый каталог. Ну если только вы не вызвали Terminate­Thread — в последнем случае описатель текущего каталога просто утёк бы, и ваша «попытка» отпустить каталог только что прогарантировала, что этого никогда не случится (заметка для технологических ипохондриков: весь этот параграф был гипотетическим и поэтому совершенно не годится для решения вашей проблемы).

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

Бонус: Привет, люди. «История ещё не закончена». Воздержитесь от спекуляций в комментариях.

Читать на сайте автора.

Это перевод What are these strange =C: environment variables? Автор: Реймонд Чен.

Вы не увидите их при выполнении команды SET, но вы увидите их, если получите список переменных окружения сами, программным путём. К примеру, если вы напишете программу, которая получает список всех переменных окружения и выводит их на консоль, и запустите её из командной строки, то увидите странные переменные с именами вроде =C: и значениями, соответствующими каталогам на этих дисках. Что это такое?

Эти переменные являются частью командного интерпретатора cmd.exe. Вот почему я добавил «и запустите её из командной строки» выше — потому что если запустить программу из Проводника или диалога «Выполнить», то вы не увидите эти переменные. Если cmd.exe не будет среди тех, кто изменял ваш блок переменных окружения, то вы не увидите переменные от cmd.exe.

Окей, командный процессор устанавливает эти переменные. Но зачем? Это остатки от попыток командного процессора имитировать старый способ, которым MS-DOS работала с дисками и каталогами. В Win32 существует только один текущий каталог, но в MS-DOS у каждого диска был свой текущий каталог. Посмотрите на такую последовательность команд:

A> CD SUBDIR
// текущим каталогом для диска A: является A:SUBDIR
A> B:
B> CD TWO
// текущим каталогом для диска B: является B:TWO
B> A:
A> DIR
// показывает содержимое каталога A:SUBDIR

В этой последовательности команд мы начинаем с A: (текущего диска) и устанавливаем его текущий каталог в A:SUBDIR. Далее, мы меняем текущий диск на B: и ставим B:TWO его текущим каталогом. Наконец, мы возвращаемся на диск A: и когда мы просим показать текущий каталог, нам выводят содержимое A:SUBDIR — потому что именно этот каталог является текущим на текущем диске.

В Win32 нет концепции отдельного текущего каталога для каждого диска, но командному процессору нужно сохранять старое поведение MS-DOS, потому что к нему все привыкли (и для этого поведения написаны базилионы командных файлов). Решение заключается в том, чтобы хранить «текущий каталог для диска» в переменных окружения, используя несколько странное имя переменной, чтобы избежать конфликта имён с другими переменными окружения.

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

A> CD SUBDIR
// Переменная окружения с именем =A: устанавливается равной A:SUBDIR
// Текущий каталог Win32 устанавливается в A:SUBDIR
A> B:
B> CD TWO
// Переменная окружения с именем =B: устанавливается равной B:TWO
// Текущий каталог Win32 устанавливается в B:TWO
B> A:
// Текущий каталог Win32 устанавливается в A:SUBDIR
A> DIR
// Показывает содержимое A:SUBDIR

Когда мы переключаемся обратно на диск A:, командный процессор спрашивает: «Эй, каким был текущий каталог на диске A:, когда я последний раз был на нём?». Для этого он пытается прочитать переменную окружения с именем =A:, которая говорит ему: «Ах, да, это был A:SUBDIR«. И именно этот каталог он устанавливает в качестве текущего.

Но почему эти внутренние переменные выносятся в переменные окружения? Разве нельзя их сделать обычными переменными внутри процесса cmd.exe?

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

C:SUBDIR> D:
D:> emacs
M-x shell
D:> C:
C:SUBDIR>
// "Текущий каталог на диске C" был сохранён - как и ожидает пользователь

Что вам тогда нужно делать с этими переменными окружения?

Ничего. Просто оставьте их в покое и дайте им делать свою работу. Я так подробно описал эти переменные, только чтобы вы не пугались их.

Читать на сайте автора.