Срочное закрытие уязвимостей PHP на серверах

Разбор уязвимостей и срочность

Исправления выпущены для веток 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официальных заплаток нет, а если PHP установлен из репозитория дистрибутива, номер версии может отличаться, поэтому ориентироваться нужно на пакет безопасности ОС. Источник советовал временные меры: отключить `session.upload_progress`, ограничить размер запросов и на PHP 8.5 отключить `fatal_error_backtraces`.

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

Инвентаризация: что на самом деле работает

На каждом сервере с PHP мы выяснили, какой PHP-FPM обслуживает сайты (на ряде серверов установлено несколько версий, но запущена одна), откуда пришёл пакет (Ubuntu или sury), включён ли модуль SOAP и есть ли обновления в индексе пакетов. Ни один пакет на этом этапе не менялся.

Главный вывод: `php -v` у дистрибутивных пакетов мало что говорит. Есть ли заплатка от конкретной CVE, видно только по changelog пакета, поэтому мы проверяли его, а не номер.

• —Разные версии Ubuntu и PHP, от 7.4 до 8.5
• —Пакеты из Ubuntu и из репозитория sury, а также PHP внутри Docker-контейнера
• —Список установленных и запущенных версий, пулов FPM и модулей

Классификация и план

Итог разбора: часть серверов уже закрыта обновлениями Ubuntu (оба CVE есть в changelog пакета), им нужна была только проверка. Три сервера с пакетами sury требовали обновления, один сервер работает в Docker, и один остаётся на устаревшем PHP 7.4.

Перед любым действием мы показали владельцу таблицу со статусами, порядком работ и оценкой риска. Боевые серверы владелец указал сам, и план утверждался по группам.

Обновление боевых по одному, с проверкой

Сначала мы обновили индекс пакетов, потому что его кэш на части серверов был устаревшим и предлагал ещё уязвимые версии. Затем ставились только установленные пакеты `php8.*`, остальное в системе не менялось. Скрипт заранее сверял кандидатов с исправленными версиями из бюллетеня и остановился бы, если версия оказалась ниже.

После установки проверялись конфигурация (`php-fpm -t`), версии, перезапуск FPM и коды ответов главных страниц всех виртуальных хостов до и после. Журналы FPM просматривались ещё пять минут. Серверы шли строго по очереди: сначала тестовый, затем боевые.

• —Пакеты ставились с сохранением текущих конфигураций
• —Версии после обновления: 8.3.36, 8.4.27 и 8.5.12
• —Списки версий до обновления сохранены для отката

Пересборка Docker-образа

Для сервера, где PHP работает в контейнере, одного обновления пакетов мало: уязвимая версия зашита в образ. Мы пересобрали образ из Dockerfile проекта с принудительной загрузкой свежей базы и получили PHP 8.4.27 вместо 8.4.25.

До замены мы проверили конфигурацию FPM нового образа и убедились, что набор модулей совпал со старым. Контейнер заменили с теми же параметрами запуска, а предыдущий образ сохранили под отдельным тегом для быстрого отката. Сайт отвечал 200 до и после.

Устаревший PHP 7.4: честная временная мера

Для PHP 7.4 на Ubuntu 20.04 исправления не существует: ни в основных репозиториях, ни в changelog последнего кандидата. Поэтому мы применили временную меру из бюллетеня: отдельным файлом в `conf.d` отключили `session.upload_progress.enabled`, не трогая основной `php.ini`, перезапустили FPM и проверили значение командой `php-fpm -i`.

Мы прямо сказали владельцу, что мера снижает риск, но не заменяет обновление, и предложили три пути: подписка Ubuntu Pro (ESM), сторонний репозиторий или переход на PHP 8.3 после проверки совместимости сайтов на этом сервере. Первую же попытку мы автоматически откатили: проверка в скрипте ошибочно приняла успешный вывод за ошибку, сервер при этом не пострадал.

Как мы проверяли и чего не делали

Мы проверяли версии пакетов, состояние сервисов, коды ответов и журналы, а не саму уязвимость: эксплойты на серверах не запускались. Это сознательный выбор: проверка эксплойтом на боевых проектах создаёт собственный риск.

Признаки взлома до обновления мы на этом этапе не искали. Для боевых серверов это отдельная работа в режиме чтения (журналы доступа, изменённые файлы, новые процессы), и мы рекомендуем сделать её следом.