Small HTTP server 3.0395

Один знакомый спросил меня по аське — что я думаю по поводу Small HTTP server. Я его отправил к статьям годичной давности (смотреть тут, тут, тут и тут). «Ну, хорошо,» — сказал он — «а что ты думаешь по этому поводу сейчас?». Ничего по этому поводу «сейчас» я не думал, моего знакомого интересовала HTTP-составляющая этого сервера, поэтому я пообещал ему произвести пару-тройку тестов и высказать своё мнение.

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

Эти результаты, оформленные должным образом, я и предлагаю вашему вниманию.

Давненько я не рассматривал замечательный продукт нашего программиста Макса Феоктистова Small HTTP server (SHS) на предмет багов и уязвимостей (в прошлом я это делал более-менее регулярно), а тем временем вышла версия 3.0395.

Small HTTP server — в прошлом HTTP-сервер, а в нынешней своей ипостаси — HTTP-, DNS-, Proxy-, FTP, POP3— и SMTP-сервер с поддержкой сервера динамических перенаправлений, виртуальных хостов, SSI, ISA и CGI-скриптов. Более всего продукт замечателен тем, что при своих возможностях он занимает всего 103 (!) килобайта.

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

Сервер я запускал в установками по умолчанию, в корень сайта положил один-единственный файл index.shtm, с SSI-командой для вывода переменных сервера.

Первая ошибка связана с обработкой GET-запроса к индексному файлу. Вообще, если сервер обнаруживает, что запрос пришел не конкретному файлу, а какому-либо директорию, обычная практика в этом случае — сервер пытается найти в этом директории индексный файл и отдаёт его содержимое, если же такой файл не найден, обычно сервер показывает содержимое директория.

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

Так вот, в случае SHS, GET-запрос к директории с какими-либо (даже пустыми) параметрами вызывает ошибку: на htt​p://127.0.0.1/? сервер отвечает \(Undefined/default) Error. File not found.

Наверное, одна из самых распространённых ошибок доморощенных веб-серверов — неправильная обработка директория «две точки». Его указание в пути файла или URL’e обычно означает, что для извлечения файла требуется подняться на директорий выше. Обычная практика веб-серверов — игнорировать две точки, если путь выходит за директорий, где лежат файлы сайта.

SHS до жути боится двух точек в URL’e, так совершенно безвредные запросы

htt​p://127.0.0.1/Folder../
htt​p://127.0.0.1/file.shml?/..
htt​p://127.0.0.1/file.shml?../

вызовут у него неадекватное bad reques (хотя ничего bad в таких requests нет).

Другая проблема SHS — негативное его отношение к слешам в конце запроса. Не то, чтобы они ему совсем не нравятся, но некоторые манипуляции с ними кажутся SHS чересчур подозрительными. Запросы ниже порождают уже знакомый «bad request».

htt​p://127.0.0.1/file.shml?./
htt​p:127.0.0.1/file.shml?

Другая беда — трансляция переменных запроса в переменные языка SSI. Видимо, преобразование URL к «нормальному» виду и отсечение всего подозрительного выполняются раньше любых других манипуляций. Так что после запроса

htt​p://127.0.0.1/index.shtm?word/
в QUERY_STRING оказывается word\index.shtm, а после

htt​p://127.0.0.1/index.shtm?/a
переменная QUERY_STRING содержит \a

Такое искажение данных недопустимо, если пытаться использовать вместе с SHS какие-либо скриптовые языки.

Собственно, даже при использовании SSI любое искажение входных данных может приводить к неожиданным, неприятным последствиям. SHS, помимо стандартной переменной QUERY_STRING, помещает данные запросы ещё и в переменные окружения, подобно тому, как это делает язык PHP. Например, запрос ?bar=1&foo=2 приведет к появлению двух переменных — bar со значением 1 и foo со значением 2.

Это очень удобно, так как позволяет использовать язык SSI для более широкого круга задач. К сожалению, и тут есть небольшой баг, искажающий внешние данные. Так запрос

htt​p://127.0.0.1/index.shtm?var==value
порождает переменную var со значением value, хотя, по логике var должна содержать строку =value.

htt​p://127.0.0.1/index.shtm?var=1=2
этот запрос, как не странно, порождает переменную var со значением… 2.

htt​p://127.0.0.1/index.shtm?&
Косметический баг. В переменных окружения — пара переменных с пустыми именами и значениями.

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

Начнем с локальных уязвимостей. Оставим в стороне CGI/ISA и другие «внешние» вещи и займемся SSI.

Несложная команда, не лишенная логики

<!-​​-#echo var="\"\"" -​​->
заставляет сервер подвисать после выполнения нескольких запросов к файлу, её содержащему.

Так же SHS не переваривает команду

<!-​-#exec cmd="\s.exe" -​-> после неё сервер выполняет недопустимую операцию и, с приличествующим шумом, умирает.

Сходная с предыдущей, команда

<!-​-#exec cmd="\"" -​->
вводит сервер в прострацию — он зависает. Что-то не так в этом королевстве с экранированными кавычками.

Удалённая уязвимость, связанная, по всей видимости, с переполнением буфера (в этом легко убедиться, несколько сократив количество знаков & в запросе). Её я приберег на сладкое.
Как уже было сказано, запрос с одним амперсандом, порождает две пустые переменные, а вот запрос длиной в 40 амперсандов

htt​p://127.0.0.1/index.shtm?&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
кончается для сервера фатально. По крайней мере, в моей Windows XP. Возможно, под другими операционками сакральное число этих знаков в запросе будет другим.

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

Повторюсь: все тесты выполнялись над версией 3.0395 под Windows XP. В качестве инструмента для всех запросов использовался браузер Internet Explorer 6.0. Сервер ставился в стандартной конфигурации, в корне сайта лежала одна-единственная страница index.shtm с командой <-​-#printenv -​-> внутри.

Вывод: Small HTTP server — безусловно отличный продукт, заслуживающий всяких похвал, но, к сожалению, недостаточно оттестированный. Для хостинга сайта, в силу постоянно обнаруживаемых ошибок в разборе HTTP-запроса, я бы его использовать не рекомендовал.

С другой стороны, в программе есть и другие сервера, которые, возможно окажутся более защищенными. Кроме того, у сервера есть неоспоримое преимущество — его размер в 103 килобайта, при таких-то возможностях. Мне видится, назначение SHS — работать на персональных компьютерах вне сети или в интранете, пока Макс не устранит эти, достойные сожаления, баги.

Кстати, до версии 1.22 обновился [ Photoshop’s Crap Remover ]. Всем, кому интересно, качайте новую версию.

Пишите!

Хочу сказать «спасибо» Спектатору — именно с его подачи я вчера попал на сайт «ПОтребитель», где прочёл статью «Куда ведёт нас Photoshop…». Статью рекомендую прочитать, хотя кое-что из того, что в ней изложено спорно, тем не менее, она мне показалась интересной.

Более всего меня заинтересовали эксперименты автора с картинками в формате JPEG/JFIF, сохранёнными из Photoshop’а. Автор утверждает, что после нехитрых манипуляций, ему удавалось сократить размер картинки на 4-6КБ — якобы Photoshop сохраняет в файле кучу никому, кроме него, ненужной информации.

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

В считанные секунды я нашел то, что меня интересовало — предельно сжатое описание формата JPEG/JFIF и занялся изучением.

Небольшое отступление касаемо аббревиатуры «JFIF». JPEG — очень широкий стандарт, JFIF же является одной из его реализаций. Честно говоря, я вообще ничего не знаю о других реализациях, но уверен, что они существуют. Как бы то ни было, Photoshop сохраняет файлы именно в формате JFIF.

Дополнение: JPEG является алгоритмом сжатия, формат файлов, сжатых по алгоритму JPEG принято называть JFIF (JPEG File Interchange Format). Есть, например, TIFF/JPEG (TIFF 6.0) — формат TIFF, сжатие по алгоритму JPEG.

Узнать JFIF-файлы очень просто — они всегда начинаются с сигнатуры JFIF в секции APP0, что следует за секцией SOI (Start Of Image), т. е. сразу после сигнатуры JPEG-файла. Все эти магические слова означают следующее — JFIF-файл всегда начинается с сигнатуры 0xFF, 0xD8, 0xFF, 0xE0, <два байта длины>, JFIF, 0x00.

JPEG, как контейнер, устроен достаточно просто — секции, называемые сегментами, их длины и содержимое. Помимо всего прочего, среди сегментов определены 16 «сегментов приложения» (APPx) и один сегмент комментария (COM). Сегмент APP0 занят форматом JFIF, как служебный, остальные 15 разрешено использовать приложениям для своих целей.

Вот именно в них Photoshop (и другие программы тоже) помещает свои данные. Например, в сегменте APP2 Photoshop хранит собственный цветовой профиль, в APP13 — некоторые установки, например, установки печати. Кажется в сегменте JFIF (APP0) может хранится пиктограмма предварительного просмотра, но мне не удалось найти ни одного файла с такой пиктограммой, чтобы произвести эксперименты по очистке файла от неё, если вам попадется файл с длинной секции APP0 хотя бы в пару сотен байт, не поленитесь, пришлите его мне.

Итак сама программа. Назвал я её незатейливо — «Photoshop’s Crap Remover» (PCR). Написана она на PHP и должна, в принципе, работать и под Unix-like и под Windows-системами. Скачать её можно у меня — 1,5КБ в архиве. Программа распространяется бесплатно для жителей России и территории бывшего СССР. Естественно запрещается использовать программу в коммерческих целях.

Если запустить программу без параметров, она даст краткие сведения о себе и своих параметрах, которых у неё негусто — при запуске с одним параметром программа в качестве выходного файла использует местный null, при запуске с двумя она обрабатывает первый файл, вычищает из него мусор и помещает результат во второй файл.

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

Photoshop’s crap remover

Опыт показывает, что более всего ненужной простому пользователю информации помещает в файл Photoshop 5.0 — после обработки его детищ детища эти действительно уменьшаются на 4—7КБ, Photoshop 7.0, для сравнения, помещает в файл всего 30—50 байт.

Под занавес две простенькие программки на Shell, облегчающие жизнь. Под Windows, естественно, работать не будут, но и под ними несложно придумать что-нибудь подобное.

# Посмотреть как изменится размер файлов в текущем каталоге, если обработать их PCR.
for file in *.jpg ; do ./pcr.php $file /dev/null; done

# Обработать все JPEG'и в текущем каталоге.
for file in *.jpg
do
    ./pcr.php $file /tmp/tmp_delete_me.jpg>/dev/null
    mv -f /tmp/tmp_delete_me.jpg $file
done

Photoshop’s Crap Remover … Скачать … . 1,5КБ в архиве.

Дополнение (от 17:46): Вышла версия 1.10, исправлена текстовая опечатка в названии сегмента, PCR научился вырезать preview, если он расположен в отдельном сегменте APP0.

Дополнение (от 18:07): Вышла версия 1.20, теперь я полностью вычищаю еще и сегмент APP0, как оказалось от этого совершенно никто не страдает — ни программы просмотра, ни браузеры, а кроме того, теперь PCR работает, как с JPEG/JFIF, так и JPEG/EXIF.

Дополнение (от 5/10/2002): Вышла версия 1.22, исправлены опечатки. Спасибо alexander (ap at mail.kuzbass.net).