PHP 8.5.12 закрывает две критические дыры, позволяющие захватить сервер без авторизации

Команда разработчиков PHP выпустила внеплановое обновление PHP 8.5.12, закрывающее две критические уязвимости. Обе позволяют удалённо выполнить произвольный код на сервере без какой-либо аутентификации.

Администраторам советуют ставить патч немедленно.

PHP остаётся одним из самых распространённых серверных языков. На нём работают WordPress, Drupal, MediaWiki, приложения на Laravel и огромное число интернет-магазинов. Уязвимости затрагивают не отдельный фреймворк, а сам интерпретатор – отсюда и масштаб проблемы.

Многие сайты сегодня не работают из-за серьёзной уязвимости PHP – экстренный патч выйдет в 17:00 по Москве

Магазин Steam упал в разгар фестиваля демоверсий на фоне критических уязвимостей в PHP

Под угрозой все установки PHP, обрабатывающие веб-запросы, независимо от способа подключения к веб-серверу:

• PHP-FPM

• Apache с модулем mod_php

• php-cgi

• FrankenPHP

• LiteSpeed

Наибольший риск разработчики видят в конфигурациях с mod_php. Для этого варианта уже показали рабочий эксплойт: один неаутентифицированный запрос запускает атаку ещё до того, как начнёт выполняться код самого приложения. Защита на уровне CMS или фреймворка в таком сценарии бессильна.

Первая уязвимость (GHSA-w8hw-w9fx-j79w) связана с обработкой нехватки памяти (out-of-memory, OOM). Когда память исчерпана, интерпретатор может прервать работу в момент, когда внутренние данные запроса инициализированы лишь частично. При очистке после запроса такие недособранные структуры принимаются за корректные, а это прямой путь к повреждению памяти и выполнению кода.

Вторая брешь (GHSA-6wmf-4rv5-p3rp) касается устаревшего глобального состояния. Данные, принадлежащие конкретному запросу, могут пережить освобождение памяти, на которую ссылаются. Если следующий запрос попадает в тот же рабочий процесс, он успевает обратиться к этому состоянию раньше, чем штатная инициализация его сбросит.

По сути это классический сценарий use-after-free, только растянутый между двумя разными запросами. В списке изменений обе проблемы объединены записью "Avoid state corruption via bailout". Bailout в PHP – механизм аварийного выхода при фатальных ошибках и превышении лимитов. Именно такие внезапные прерывания и оставляли внутреннее состояние интерпретатора в несогласованном виде.

Основной способ защиты – переход на PHP 8.5.12. Дистрибутивы Linux и поставщики расширенной поддержки (LTS) получили исправления заранее, так что свежие пакеты стоит искать у своего вендора. Ветки PHP 8.1 и старше официально уже не поддерживаются, но часть дистрибутивов и LTS-поставщиков переносит исправления и на них.

Из-за серьёзности угрозы команда безопасности PHP сделала исключение и подготовила минимальные бэкпорты исходного кода для PHP 7.4, 8.0 и 8.1. Они пригодятся тем, кто собирает интерпретатор из исходников или не имеет доступа к коммерческой поддержке. Всем остальным советуют перейти на поддерживаемую версию.

Для тех, кто не может обновиться сразу, опубликован набор временных мер. Разработчики честно предупреждают – они лишь сужают отдельные векторы атаки и не делают установку безопасной:

• против первой уязвимости выставить `memory_limit=-1` так, чтобы приложения не могли переопределить значение (например, через `php_admin_value` в пуле FPM или конфигурации Apache), и проверить, что ни один пул, каталог или приложение не возвращает конечный лимит

• снизить `post_max_size` до 8M для приложений без загрузки файлов и до 32M, если загрузки нужны, удерживая `upload_max_filesize` ниже этого значения

• ограничить на уровне веб-сервера или прокси размер декодированного запроса, число полей ввода, частей multipart и заголовков, а также глубину вложенности, в том числе для запросов без корректного Content-Length

• использовать лимиты контейнера или cgroup с политикой завершения только затронутого воркера, но не `RLIMIT_AS` и `RLIMIT_DATA`, так как они сами способны вызвать уязвимый сбой выделения памяти

• против второй уязвимости задать `session.upload_progress.enabled=0` в php.ini, пуле FPM или конфигурации сервера, которая применяется до разбора запроса, и перезапустить все воркеры

• в PHP 8.5 выставить `fatal_error_backtraces=0` и тоже перезапустить все воркеры

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

У каждой меры есть ограничения. Параметр `memory_limit=-1` снимает лишь контролируемый сбой лимита памяти PHP, а реальная нехватка памяти на уровне системы всё равно способна привести к уязвимому участку кода. Отключение прогресса загрузки сессий закрывает только подтверждённые пути атаки через сессии, а `ini_set()` и `.user.ini` в FPM для этой настройки не подходят.

Скрыть проблему через `error_reporting`, `display_errors` или оператор `@` тоже не выйдет. Команда PHP выражается однозначно.

Полноценных мер смягчения не существует, обновление – единственный безопасный выбор.

Помимо двух критических брешей, в PHP 8.5.12 вошли десятки исправлений в ядре и расширениях. В Opcache устранили переполнение буфера в куче внутри оптимизатора и несколько ошибок трассирующего JIT-компилятора, из-за которых код выдавал неверные результаты. В одном из случаев JIT записывал приватное свойство родительского класса в одноимённое публичное свойство дочернего.

В библиотеку Lexbor, на которой построены новый парсер `Dom\HTMLDocument` и работа с URL, влили патчи против переполнения буфера в куче при разборе `:lexbor-contains()` и ряда ошибок обработки адресов. Также закрыли несколько use-after-free в расширениях BZ2, SOAP, DOM, Tidy, SimpleXML и PDO. А `mb_strpos()` больше не читает данные за пределами строки, оканчивающейся обрезанной последовательностью UTF-8.

Встроенный сервер CLI перестал терять файловый дескриптор при каждом HEAD-запросе к статическому файлу. Починили и ситуацию, когда PHP сообщал о поддержке AVX, хотя операционная система не включила соответствующее состояние процессора. Функцию `pg_service()` из расширения PGSQL удалили, поскольку она недоступна ни в одной выпущенной версии libpq.

PHP распространяется бесплатно и доступен для Windows, macOS и Linux. Полный список изменений опубликован на официальном сайте php.net.