Класс ошибок Devicefile Crash. Довольно распространенная ошибка, позволяющая
осуществлять удаленные DoS-атаки на Windows-приложения.
Предположим, программа должна прочитать файл с диска, если нет - перейти
к обработчику ошибки. Обычный алгоритм, используемый программистами, описанный
в учебниках по Паскалю 😉 и т.д. выглядит примерно так:
открыть файл
если ошибка то
сообщить "файл не существует"
выход
иначе
длина=0
ИнициализироватьБуфер()
пока Не КонецФайла Выполнять
длина=длина+ПрочитатьФайл(буфер)
КонецЦикла
ОбработатьСодержимое(длина,буфер)
ВывестиРезультат
конец если
Конечно, перед открытием неплохо бы проверить, действительно ли существует
запрашиваемый файл и узнать его длину, но многим это кажется лишним - ведь если
файла нет, первая строка возвратит ошибку, а длину файла можно получить через функцию
чтения, как описано в примере. Кроме того, при реализации проверки на наличие
файла в мультиплатформенных программах возникают дополнительные сложности.
Однако, во многих OS существуют имена файлов, открытие которых возможно, однако
это вовсе не означает, что из этих файлов можно безопасно читать. Речь идет о
файлах устройств. В Unix-системах это файлы из каталога /dev, в DOS/Windows -
COMx, LPTx, CON, PRN, AUX и т.д. Функция чтения из такого файла будет ожидать некоторое
количество данных, пришедших из порта, обычно равных размеру буфера. При этом
вовсе не факт, что эти данные когда-нибудь туда попадут.
В IIS4/5 обнаружены две таких ошибки (вместо com1 нужно подставить имя
существующего в системе устройства).
http://host/com1.asp - возвращает пустой ответ, а иногда - требование NTLM-авторизации (только не спрашивайте, пожалуйста,
почему...)
http://host/com1.idq - говорит error processing file, т.е. открывает его,
и уже потом как-то понимает, что файла-то нет.
К сожалению, из-за отсутствия под рукой (в локалке) IIS и от глобального
нежелания его ставить, я не определил, приводят ли эти ошибки к зависанию
чего-либо или расходу ресурсов, так что единственно пока
найденное применение - определить, есть ли такой порт на удаленном сервере 🙂
Если нет, то получается обычная 404 в первом случае и file not found во втором.
Теперь - об уязвимостях, основанных на данной ошибке. В основном они
касаются Win32, т.к. в Unix имя файла содержит путь, который создатели
скриптов уже привыкли фильтровать. Кроме того, можно ограничить права
доступа к /dev для пользователя, с правами которого исполняются скрипты.
С Windows, где файлы устройств "лежат" в каждом каталоге, такое не пройдет.
Потенциальной жертвой может быть, например, серверное приложение, каким-либо
образом получающее от пользователя произвольное имя файла и затем читающее его.
Впервые ошибка была обнаружена в Frontpage Extension 3, при аплоаде файла
для отсылки результатов формы через shtml серверные расширения вышеописанным
образом читают файл, указанный в качестве
места назначения результатов формы, и при указании COMx (какого-либо существующего порта сервера) "уходят в себя".
Ошибка трехлетней давности, так что подробности не помню.
Более свежий случай - tradecli.dll - 1С: Аркадия для 7.5.
Совсем нехорошо, если такая ошибка встретится в интерпретируемых серверных
скриптах - эксплоит приведет к зависанию интерпретатора и, соответственно,
невозможности выполнения всех скриптов такого типа. Пример - файл viewasp.asp
на www.asp101.com. Символично, что создатели сервера, призванного научить весь
мир программированию на .asp, делают ошибки в собственных скриптах.
Кроме того, есть возможность "повесить" интерпретатор хостинга,
сознательно сделав "ошибку" в своем скрипте. Например,
в том же .asp открыть COMx через Scripting.FileSystemObject и попытаться
что-нибудь оттуда прочитать.
Есть сильное подозрение, что после подвисания в логи IIS не попадает информация
о последнем запросе, ведь в логе должен фигурировать код ошибки, который вернула
подсистема, а такой код, как "зависание", создатели подсистемы вряд ли
предусмотрели 🙂
Для общего развития, побродив по Яхе, нашел еще парочку
уязвимых скриптов. По статистике (сами понимаете, небогатой), уязвимым оказался каждый третий
скрипт, получающий имя файла в качестве параметра.
Например wsisa.dll, ispage26.dll
Как избежать этой ошибки?
Перед открытием файла надо проверять функцией FindFirst, существует ли он. Для
windows-приложений этого достаточно.
