Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 57
https://php2shell.ru - методы зщаиты от PHP2Shell и ссылки на патчи, информация обновляется.
Спамить плохо
Зависть? Человек помощь сообществу хочет!
Пусть придумает другой способ, все его комментарии это спам этой ссылкой. Если применять критерий полезности для общества, то окажется, что всем можно спамить чем угодно где угодно, а это, очевидно, вредно.
P.S. Если оценивать текст сайта, то первый же рекомендуемый способ исправления уязвимости (не считая самого патча), судя по [1], на самом деле не работает. На сайте даже нет почты для обратной связи, поэтому @unsec никогда бы не узнал, если у него что-то написано не так.
Не открывается.
информация обновляется
Таки похоже, что есть и третья уязвимость:
Уязвимы ли совсем старые версии PHP? До сих пор есть сайты, которые работают на 5.X
да, уязвимы
5.4 включительно
Sansec wrote “PHP 5.4 or later” and watchTowr named versions 5, 6, 7 and 8, which includes a PHP 6 that never shipped. The advisory lists patched versions for 8.2 through 8.5 only, and the mechanism goes back further than the rumor, since the same jump sits in the PHP-5.3 allocator. I have not seen an exploit shown on those old versions either.
Хорошие новости, патч выпущен также и для 7.4.*, 8.0.* и 8.1.*
https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619
https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619
https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619
Так ведь получается достаточно уменьшить на фронтенде макс размер файла до меньшего размера, чем указано в memory_limit/post_max_size/upload_max_filesize, чтобы еще на уровне nginx запрос обрывался с 413 (или apache c 400), и утечка памяти была бы невозможной, т.к. memory_limit бы и не дергался (это касается CVE-2026-109618)
Проблема еще в том, что memory_limit может быть задан в php.ini и потом еще 10 раз изменен в .htaccess и самих php скриптах. Причем как в большую, так и в меньшую сторону. Много раз наблюдал когда изначально стоит допустим 1024мб лимит, но скрипт обрывается с ошибкой по памяти. В итоге выясняется что где-то в недрах скриптов зачем-то стоит невозмутимая строчка типа ini_set(‘memory_limit’, '128M');
А если в nginx сделать совсем уж малое значение, то появиться могут проблемы у нормальных запросов.
Во многих дистрибутивах уже забэкпортили фикс на более старые версии PHP - тем не менее, скрипт выдает, что уязвимость есть.
php8.3 (8.3.6-0ubuntu0.24.04.13) noble-security; urgency=medium
SECURITY UPDATE: Remote RCE via state corruption issue
<...>
CVE-2026-109618_109619.patch
Оперативно обновился до 8.4.27 , образ интернет магазина в докере. Стояла 8.4.18 , правда репу пришлось поменять .. в той что была последняя версия 8.4.26 была. Mailcow сборка тоже еще не обновились .. последняя версия 8.2.29 установлена.
Для Ubuntu Ondřej Surý (официальный maintainer пакетов PHP в Debian и Ubuntu) поддерживает сборки PHP вплоть до 5.6.
Сегодня он выкатил обновления для всех поддерживаемых им версий, т.е. есть собранные бинарники для РHP 5.6, всех 7.x и всех 8.x.
@Gnidenko стоит добавить ссылку на PPA для Ubuntu в статью, чтобы было заметнее.
Да, товарищ Ondřej Surý прям выручает. Правда серверы у него теперь перегружены, судя по периодическим 503-им...
Используйте зеркало https://mirror.yandex.ru/mirrors/packages.sury.org/php/
К тому же с 2024 он блокировал российские IP. Сейчас не знаю, у меня почему-то обновилось с его репозитория.
автор этих пакетов (Ondřej Surý) официально объявил о миграции репозиториев Ubuntu с нестабильной платформы Launchpad PPA на собственные выделенные серверы packages.sury.org
и вчера обновления на sury.org появились раньше чем на launchpad.net
Ондржей в очередной раз спасает половину мирового веба в одиночку, мужик буквально держит на своих плечах легаси миллионов серверов...
Теперь нужен скрипт для поиска руткитов.
Руткит называется так потому, что работает с правами рута. В данном случае, даже если вы сумеете пробиться сквозь эту дыру внутрь сревера, а это капец как сложно, то сможете запустить что-нибудь с правами пользователя, от имени которого работает php, например, www-data. Эскалировать права до рута - задача ещё сложнее, чем вломиться в сервер.
Эксплойты то показали хоть один?
Обновился на своем серваке, Debian 13 все подкатилось оперативно... А что будет с вебом у хостеров можно себе только вообразить... Мамкины кулхацкеры и серьезные дядьки будут штурмовать в ближайший год-два все что шевелится.
Совет выставить memory_limit в минус один на проде без жестких внешних cgroups закончится тем, что первый же тяжелый экспорт положит сервер по OOM-киллеру
Уязвимы обработчики форм с загрузкой файлов multipart/form data. Если загрузки файлов нет, можно и не переживать.
Чтобы таким образом не переживать, нужно сначала отключить данный функционал для всего PHP. Запрос с multipart/form отправить на ваш сервер никто не мешает, даже если у вас нет функционала его обработки.
Как таким способом вызвать переполнение памяти? в этом ведь корень проблемы?
Отправить большой запрос. Опционально - ещё и в формате gzip-бомбы. Что именно здесь непонятного?
Он не будет обрабатываться, если нет эндпойнта и обработчика, так бы и вешали любые сервера, шли "большие запросы", или gzip бомбу куда захочется, никакой ddos и не нужен.
Он будет записан в $_FILES ещё до того, как ваш фреймворк получит управление и увидит что нет обработчика.
Вот это формирование $_FILES и вызывает OOM. Если что, под OOM тут понимается выход за внутренний memory limit отведённый запросу, а не системный.
Обычно этот memory limit как раз и защищает сервер от DoS, но в этот раз в его обработке обнаружилась проблема.
Почему-то эти два дня я вижу много таких сообщений от людей, которые упорно думают, что уязвимость случается только если php-скрипт что-то делает, и если в скрипте что-то не делать - то дыра-то у них в безопасности!
Но это не так. Уязвимость не в каких-то конструкциях языка. Уязвимость глубоко в ядре, и абсолютно любой сервер без обновления уязвим независимо от своей настройки.
Где код эксплоита ? Как проверить свой сервер ?
"свой", ага...
Ну в данном конкретном случае мне надо проверить пару свои серверов.
лучше проверь версию PHP если так переживаешь... эксплоит ему подавай
У меня версия PHP на серверах "очень старая", апгрейдить невозможно, это утянет кучу всего - работы на месяц (если не больше). Я применил ряд затычек и хочу проверить на сколько они эффективны. Во Фре, кстати, есть рандомизация виртуальных адресов и стека (ASLR), мне кажется что это должно сильно усложнить создание эксплоита.
Уже есть бэкпорты патчей под все уязвимые версии.
ASLR есть и в Linux и он не спасает от этой уязвимости. В век нейросетей вообще особенно опасно думать, что под редкую ось никто эксплойт не напишет.
Особая опасность этой уязвимости ещё и в том, что её можно очень по-разному использовать, так что защититься от какого-нибуть одного способа сделать странный запрос недостаточно, чтобы спать спокойно.
Блин, когда вижу код PHP прям отдает таким вайбом детства, школьных лет 😅 Давно ж это было 🌚 Тогда еще v3 актуальна была.А еще была такая штука как PERL… Мдо.
Да, чуть не забыл, а эксплоит то где взять? Это не мне, друг попросил 😅
дулинго изза этого не работает?)
php-расширение которое можно собрать для любой старой версии - хороший вариант? https://github.com/HOSTED-POWER/php_uploadprogress_guard
Проблема НЕ в upload_progress. Это какая-то хроническая боль в интернете - все ломятся его отключать, думая, что тем самым они решили проблему. Но upload_progress это всего лишь теоретическийй способ атаки и его отключение - попытка избежать некоторых возможных сценариев атаки. Вот только бесполезно пытаться защищаться от известных способов эксплуатации, когда всегда могут появиться новые способы буквально через день или даже через минуту.
Понятно, почему хостер (по ссылке видимо кто-то из хостеров) пытается найти обходные пути попроще и побыстрее. Ему обновить множество уязвимых версий на тысячах сайтов довольно сложно, надо что-то сделать уже сейчас. Но это как прикладывание подорожника для лечения сахарного диабета. И далее хостеру не избежать массового обновления.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP2Shell: две RCE в ядре PHP без авторизации. Кто уязвим и как проверить сервер за минуту