Архив метки: PHPFPM

Почему инцидентов с эксплуатацией PHP2Shell так мало?

Почему инцидентов с эксплуатацией PHP2Shell так мало?

Почему инцидентов с эксплуатацией PHP2Shell так мало? С самого начала PHP2Shell сравнивали с громкой уязвимостью Log4Shell (CVE-2021-44228). Однако механизмы эксплуатации этих уязвимостей существенно различаются. В случае Log4Shell злоумышленникам достаточно было отправить короткий фрагмент текста уязвимому приложению. Если приложение записывало этот текст в журнал, атака срабатывала. Один и тот же текст работал практически против любой уязвимой цели без изменений. Поэтому злоумышленники могли запускать массовые атаки, и многие из них оказывались успешными. Уязвимости PHP2Shell устроены иначе. Эксплуатация зависит от состояния кучи памяти (heap), используемого менеджера процессов, повторного использования рабочих процессов и особенностей размещения памяти в конкретной сборке. Поэтому эксплуатировать PHP2Shell не так просто, как Log4Shell.

Чтобы оценить реальную эксплуатабельность, эксперты Tenable с 24 по 29 октября выставили пять уязвимых PHP-сайтов в Интернет. Они зафиксировали массовые попытки эксплуатации PHP2Shell, но ни один ханипот в итоге не был взломан. 🤷‍♂️

В ходе анализа эксплоитов эксперты Tenable пришли к выводу, что повреждение памяти действительно существует и одним из последствий может быть раскрытие содержимого памяти. Однако добиться выполнения кода на конкретной цели сложно, причём метод эксплуатации уникален для каждой цели. Для успешного удалённого выполнения кода экспертам Tenable потребовался эксплойт, настроенный под конкретную среду, включая сборку PHP, SAPI, расширения и конфигурацию среды выполнения ("extensions and runtime configuration"). Пейлоад, работающий в одной лабораторной конфигурации, не подходит автоматически для другого дистрибутива или другой конфигурации пула PHP-FPM.

Эксперты Tenable подчёркивают, что отсутствие доказательств простой массовой эксплуатации не делает уязвимость безвредной. Злоумышленник, нацелившийся на конкретную систему, может создать подходящий эксплойт (тем более сейчас, используя AI-инструменты). Массовые атаки по сценарию Log4Shell менее вероятны, кроме систем с одинаковыми сборками, например сетевых устройств, где эксплойт достаточно настроить один раз.

Всё это не значит, что PHP2Shell можно игнорировать: условия для эксплуатации существуют, а целевые атаки на PHP-приложения вполне вероятны. Рекомендуется обновиться до PHP 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо установить исправленные пакеты дистрибутива. Для неподдерживаемых веток следует запланировать переход на актуальную версию PHP, а пока ограничить доступ из Интернет и применить меры защиты на уровне конфигурации. Для сетевого оборудования используйте исправленные сборки производителя или рекомендованные им временные меры защиты.

Рекомендуемая последовательность: сначала обновить или изолировать сетевые устройства, открытые интерфейсы управления и системы с неподдерживаемыми версиями PHP. Остальные PHP-системы обновлять по графику критических обновлений. И не забывайте о других уязвимостях, которые могут представлять более высокий риск для вашей инфраструктуры. 😉

Продолжаем разбираться с PHP2Shell

Продолжаем разбираться с PHP2Shell

Продолжаем разбираться с PHP2Shell. В 17:00 по Москве на сайте PHP был опубликован бюллетень "Уведомление о безопасности: критические уязвимости, позволяющие удалённо выполнять произвольный код" с призывом немедленно обновить ПО.

В PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 исправлены две критические уязвимости, позволяющие злоумышленникам удалённо выполнять код без аутентификации. Всем пользователям PHP настоятельно рекомендуется немедленно обновиться. Риску подвержены все серверы, использующие PHP для обработки веб-запросов, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольшему риску подвержен mod_php. Уже подтверждена возможность удалённого выполнения кода через запрос без аутентификации, ещё до начала выполнения кода приложения.

🔻 RCE из-за нехватки памяти (OOM), CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): при нехватке памяти PHP может прервать выполнение, когда внутренние данные запроса инициализированы лишь частично. При очистке запроса эти некорректные данные могут быть ошибочно приняты за действительные.

🔻 RCE из-за устаревшего глобального состояния (stale global state), CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): внутренние данные запроса могут сохраняться после освобождения занимаемой ими памяти. Следующий запрос, обрабатываемый тем же рабочим процессом, может использовать эти устаревшие данные до их сброса при инициализации.

Вектор для обеих уязвимостей CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.2)

Как обновиться:

🔹 Обновите PHP до версии 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Скачать исходный код можно на странице загрузок. Исходный код и готовые сборки для Windows доступны на отдельной странице.

🔹 Для Linux вендоров исправления были переданы заранее. Проверьте, доступны ли обновлённые пакеты у вашего вендора. Например, для Red Hat или Ubuntu.

🔹 PHP 8.1 и более старые версии больше не получают обновлений от команды PHP. Однако из-за серьёзности уязвимостей команда безопасности PHP подготовила исправления исходного кода (minimal source-backports) для PHP 7.4, PHP 8.0, PHP 8.1.

Также в бюллетене приводятся компенсирующие меры, которые "помогут снизить риск некоторых видов атак, но не сделают систему полностью безопасной". Подчёркивается, что полноценное решение - только обновление.