1. Вступление
Apache – это мощный веб-сервер с открытым исходным кодом, безусловный лидер среди Web-серверов в сети Интернет (используется более чем в 60% случаев).
По данным netcraft.com на ноябрь 2006 года
Apache 61.44%
Microsoft 31.35%
Sun 0.34%
Zeus 0.53%
Одной из причин его популярности является гибкость, легкость изменения конфигурации, что обеспечивается за счет модульной архитектуры сервера.
Apache состоит из ядра и подключаемых к нему модулей.
Ядро веб-сервера выполняет лишь основные функции (читает конфигурационный файл, принимат запросы клиентов, ...) и предоставляет набор сервисов модулям.
Модуль – это программный код, расширяющий функциональность сервера. Реализуются либо в виде динамических библиотек, загружаемых в адресное пространство сервера, либо (реже) компилируется статически вместе с ядром.
1.1. Динамический контент
Он может:
а) запускаться веб-сервером как отдельный процесс и общаться с ним через интерфейс CGI (такую возможность предоставляет модуль mod_cgi)
б) подгружаться к серверу как модуль (mod_php, mod_perl, mod_python, mod_ruby, mod_tcl, ...)
В первом случае при каждом запросе клиента Apache запускает отдельный процесс интерпретатора. После обработки запроса процесс завершается и полностью удаляется из памяти.
Главный недостаток такого подхода – большая ресурсоемкость.
Преимущества состоят в следущем:
1) изоляция процессов (интерпретатор выполняется отдельно от сервера и не может нарушить его работу)
2) появляется возможность запуска интерпретатора из-под другой учетной записи (mod_suexec)
Если интерпретатор работает как модуль веб-вервера, то он загружается в память лишь один раз (при запуске сервера) и остается в ней в течение всего времени работы сервера. Фактически, скрипты в таком случае выполняются самим процессом web сервера.
Это наиболее быстрый и эффективный способ выполнения скриптов
Однако выполнение скриптов внутри веб-сервера ведет к проблемам с безопасностью:
1) ошибка в модуле может привести к краху всего веб-сервера
2) интерпретатор, а следовательно и скрипты, выполняются с правами веб-сервера. Это особенно опасно на т.н. «виртуальных хостингах» (shared hosting). Защищенность системы определяется самым слабым звеном: уязвимость в скрипте на одном из сайтов может привести к компрометации всех остальных.
3) кроме того, во многих интерпретаторах скриптовых языков существует уязвимость, о которой я бы хотел рассказать подробнее: утечка файловых дескрипторов.
2. Проблема
В скриптовых языках есть функции для запуска внешних бинарных файлов. Проблема заключается в том, что процесс, запущенный через эти функции, получает в наследство от веб-сервера все его файловые дескрипторы, включая дескрипторы лог-файлов и сокетов.
Разберемся, почему это происходит. Запуск бинарного файла в Unix системах происходит в 2 этапа:
а) Создание нового процесса. Единственный способ породить новый процесс – это системный вызов fork(). Процесс-ребенок является почти полной копией родительского процесса, наследует все основные его характеристики, в том числе открытые файловые дескрипторы.
б) Системный вызов exec(), который заменяет программу, выполняемую текущим процессом, на программу, загруженную из указанного файла. Все открытые прежней программой файлы остаются открытыми (с теми же дескрипторами).
Имеется одно исключение: если у файлового дескриптора установлен флаг FD_CLOEXEC, то при вызове exec() соответствующий файл закрывается.
Итак, установка флага FD_CLOEXEC на дескрипторы веб-сервера решила бы проблему с утечкой дескрипторов. Однако веб-сервер Apache не делает этого.
Второй способ решения данной проблемы: закрытие дескрипторов самим интерпретатором, между вызовами fork() и exec(). Однако большинство из них этого не делают. Мы протестировали 5 популярных интерпретаторов последних версий:
Из них только Ruby перед выполнением внешней программы закрывает лишние дескрипторы.
3. Возможности
Таким образом, если на сервере есть уязвимый скрипт (например, с php-инклудингом), и имеется возможность запускать бинарные файлы, то мы можем запустить там программу, которая получит привилегии веб-сервера и все его дескрипторы.
Что же можно сделать, имея дескрипторы Apache?
1) Работа с лог-файлами любого виртуального хоста, работающего на данном сервере:
– чтение
– удаление записей, обнуление (например, чтобы скрыть следы взлома)
– запись поддельных сообщений
2) Самое интересное, пожалуй: работа с сокетами.
– подмена веб-сервера. Программа-exploit выполняется с теми же правами, что и Apache. Следовательно, она имеет возможность посылать сигналы веб-серверу. Послав сигнал SIGSTOP, мы можем остановить серверные процессы, и начать сами обрабатывать входящие соединения.
exploit, который, будучи запущенным через функции PHP exec() или system(), подменяет собой веб-сервер.4. Заключение
а) Команда “Hackerdom” обнаружила эту проблему в конце августа 2006 года. Мы сообщили об этом разработчикам PHP. Они признали наличие проблемы, но отказались ее решать, ответив, что проблема заключается не в PHP, а в веб-сервере Apache. Объяснили они это так: «файловые дескрипторы открываются веб-сервером, он и должен заботиться об их безопасности»
Разработчики Apache не считают данную утечку проблемой сервера. «Не запускайте код, которому не доверяете в привилегированном процессе веб-сервера. Выполняйте скрипты через CGI»
Как оказалось позже, проблема была озвучена еще в 2002 году и до сих пор не была решена.
б) Мы провели небольшое исследование виртуальных хостингов, чтобы узнать, насколько актуальна данная проблема. Мы задавали 2 вопроса в службы поддержки:
– возможно ли выполнение скриптов через mod_php ?
– можно ли запускать бинарные файлы через функцию exec() ?
Как оказалось, на 35% хостингов возможно и то, и другое.
в) В заключение нужно отметить, что в
– версии Apache Server для Windows
– Microsoft IIS Web Server?
утечки дескрипторов нет