Невозможно полностью устранить две критические уязвимости PHP под названием PHP2Shell до выхода сегодняшнего исправления, а предложенное в качестве временного решения изменение настроек само по себе недостаточно, как теперь заявляет фирма, предложившая его. PHP выпустит исправление в 14:00 UTC 21 октября для двух уязвимостей, которым присвоен рейтинг 9,2 из 10, и не предоставила собственного обходного пути. До установки исправления снизить риск можно, отключив уязвимые PHP-сервисы от интернета или ограничив к ним доступ, сократив возможности скомпрометированного сервера и подготовив обновление к моменту его выхода.
Сообщений об атаках не поступало. PHP не уточнила, какие версии затронуты, какая часть PHP задействована или влияет ли изменение каких-либо настроек на риск; компания заявляет, что полные сведения и исправленные версии будут опубликованы вместе с релизом. На момент написания статьи релиз еще не вышел. Поэтому никто, кроме группы, обнаружившей уязвимости, не может проверить, работает ли предложенная защита, поэтому приведенные ниже рекомендации направлены на снижение риска, а не на гарантию безопасности.
Распространенное в социальных сетях и блогах по безопасности временное решение заключается в добавлении одной строки в файл конфигурации PHP: session.upload_progress.enabled=0. Это отключает функцию Session Upload Progress, включенную по умолчанию в PHP, которая записывает прогресс загрузки файла, чтобы другой запрос мог отслеживать его.
Токийская фирма по безопасности GMO Flatt Security предложила установить эту настройку в начале 21 октября, заявив, что не может быть уверена, что изменение полностью устраняет уязвимости, но думает, что оно поможет с некоторой вероятностью. Позже в тот же день фирма отозвала свое заявление. В обновлении, датированном 14:00 по японскому времени (05:00 UTC), было сказано, что сама по себе эта настройка не является полным исправлением, и ожидаются атаки, обходящие ее. Администраторам рекомендовано подготовить обновление, отслеживать трафик атак до выхода релиза и применить исправление, как только оно станет доступно.
Разработчик ядра PHP высказался более прямолинейно. Отвечая на предположение о том, что настройка upload-progress может исправить уязвимость, Джина Питер Баньярд, разработчик ядра PHP и автор документации, финансируемый PHP Foundation, написала: «Единственное, что я могу сказать, это то, что единственная мера — это исправление/обновление PHP. К сожалению, я знаю слишком много».
На настройку нельзя полагаться по двум причинам. GMO Flatt ожидает появления способа ее обойти, но не сообщает, в чем он заключается. И вся идея о том, что уязвимость находится в Session Upload Progress, является догадкой: PHP это не подтвердила, сама фирма заявила, что это верно лишь в той мере, в какой ее собственные исследования соответствуют PHP2Shell, а независимый аудит кода утверждает, что конкретный баг, описываемый другими в этой функции, отсутствует в выпущенных версиях PHP. Этот аудит выполнен анонимным аккаунтом, и собственный код PHP расставит все точки над «i», но это еще одна причина не рассматривать эту настройку как щит.
Не все согласны. Один из поставщиков, Upwind, по-прежнему перечисляет эту настройку как немедленную меру, передавая анализ другого исследователя, а не собственные тесты. watchTowr, которая воспроизвела одну из уязвимостей, заявляет, что «на данный момент подтвержденного исправления или обходного пути нет».
Никто не призывает отменять это изменение. Инструкция заключается лишь в том, чтобы не считать его защитой. Собственное руководство PHP уже рекомендует отключать эту функцию там, где приложение не использует индикаторы прогресса загрузки, поскольку имена хранимых файлов и полей «не проверяются и могут содержать PHP-код». Если вы включили ее по ошибке там, где она необходима, единственная цена — это прекращение работы индикаторов прогресса загрузки.
Убедитесь, что изменение действительно вступило в силу для процесса, обслуживающего веб-трафик, а не для командной строки. Настройка имеет тип INI_PERDIR, поэтому ее можно установить в php.ini, .htaccess или .user.ini.
Файл .user.ini доступен только для чтения версиями PHP CGI и FastCGI, но не модулем Apache, и PHP повторно считывает его по умолчанию только каждые 300 секунд, поэтому изменение может занять до пяти минут. В случае с модулем Apache используйте .htaccess или конфигурацию сервера. Подтвердите значение для PHP-FPM или mod_php, в зависимости от того, что обслуживает ваш сайт, а не через php -i в командной строке.
Подготовьтесь сейчас. Рекомендация GMO Flatt — подтвердить шаги обновления и последующие проверки, отработать любые изменения конфигурации и заручиться поддержкой людей и разрешений для возможного экстренного перезапуска. Когда исправление выйдет, обновите среду выполнения, обслуживающую веб-запросы, то есть PHP-FPM, mod_php или CGI, а не приложение поверх нее.
PHP выпускает исправления только для своих четырех поддерживаемых ветвей: от 8.2 до 8.5. Какие именно версии содержат исправление и насколько далеко распространяются уязвимости, будет объявлено вместе с релизом. The Hacker News ранее сообщал о поддержке ветвей и более широком контексте в своем предыдущем освещении раскрытия информации.
В случаях, когда немедленное обновление невозможно, CERT-EU рекомендует организациям «рассмотреть возможность изоляции приложений, доступных из Интернета, от общедоступных сетей до применения исправления». Баньярд высказал ту же мысль изнутри проекта: отключение сервера на день «может быть самым разумным решением». Но это далеко не разумное требование для большинства людей. В крайнем случае, помимо отключения, ограничьте доступ: поместите сайт за VPN, в список разрешенных клиентов или обеспечьте аутентифицированный доступ на периметре и убедитесь, что трафик не может достичь источника напрямую в обход этих мер контроля.
Уменьшите объем данных, которые злоумышленник получит в случае компрометации сервера. Другие шаги GMO Flatt включают сокращение объема данных, хранящихся на сервере, уменьшение его привилегий, удаление сохраненных учетных данных, включая облачные роли, и обеспечение включенного ведения журналов в безопасном месте для последующего расследования.
Ветви старше 8.2, включая 8.1, 7.x и 5.x, являются устаревшими и не получают исправлений от PHP. Для них необходимо обновить систему, вывести ее из эксплуатации или изолировать; дистрибутив Linux или хостинг-провайдер может бэкпортировать исправление по своему графику.
Веб-приложение межсетевого экрана (WAF) здесь является слабым временным решением, а не исправлением. Cloudflare добавила экстренные правила «аномального выполнения» 21 октября, но в ее журнале изменений не упоминаются ни PHP, ни эти уязвимости; такие правила видят только трафик, проходящий через провайдера, и могут пропустить варианты. Обновление WordPress, Laravel или другого приложения не обновляет лежащую в основе среду выполнения PHP; это происходит из вашего серверного пакета, хоста или образа контейнера. На управляемом или общем хостинге спросите у своего провайдера, когда будет доступен исправленный сборка PHP, и попросите их быть наготове.
Хостинг-провайдеры создают свои пакеты только после того, как PHP выпустит исправление: CloudLinux, например, заявляет, что их обновленные пакеты зависят от выпуска вышестоящей версии и будут опубликованы, когда будут готовы.
Эксплуатация уязвимостей не сообщалась: FAQ watchTowr не содержал информации об этом по состоянию на 21 октября, и эти уязвимости отсутствовали в каталоге CISA известных эксплуатируемых уязвимостей при последней проверке. Было опубликовано и затем удалено короткое демонстрационное видео, а вышеупомянутый аудит утверждает, что циркулирующий код proof-of-concept не срабатывает. Относитесь к этому как к снимку, который может измениться.
Когда выйдет исправление, проверьте исправленную версию для вашей ветви, какие версии PHP перечисляет как затронутые, подтверждает ли или отвергает PHP какие-либо настройки в качестве смягчения последствий, и изменился ли код сессии, что также прояснит спор о том, где находится уязвимость. Исправленные версии и консультативное заключение появятся на php.net и через GitHub security advisories PHP, где проект присваивает собственные идентификаторы. После обновления проверьте свои журналы на наличие чего-либо, произошедшего до установки исправления.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
