Эксплойта для этой уязвимости в PHP попросту нет — несмотря на тысячи «PoC» на GitHub
There isn't an easy exploit for this PHP vulnerability
Уязвимость в PHP реальна, но паника вокруг неё не оправдана: все гуляющие по GitHub «эксплойты» не работают против чистой установки. Многие цепочки атаки требуют, чтобы сервер уже был скомпрометирован через LFI — то есть фактически выполнял eval(read(файл_от_пользователя)). Автор связывает это с LLM: Claude и GPT выдают нерабочие PoC и даже сами вносят уязвимость в тестовый сервер, чтобы «доказать» атаку. Это не Log4Shell.
Прошло 10 часов с момента публикации уязвимости, половина мира софта смотрит на неё, и уж точно 100 000 человек подключили к делу свой «сверхразум». И всё же рабочего эксплойта нет.
- nallerooth
Это такое странное заявление от человека, который пытается звучать знающим в области кибербезопасности (может, он и есть, я понятия не имею, кто это). Даже если эксплойт было бы сложно использовать правильно, это не значит, что в мире недостаточно групп, которые пытаются.
Любой серьёзный человек в этом деле учёл бы тот факт, что работающий PoC был передан команде безопасности PHP. Они подтвердили уязвимость и начали поднимать много шума по поводу её серьёзности, сообщив о 2 CVE и продвинув патч в дистрибутивы Linux до официального релиза патча.
Пытаясь понять, в чём вообще посыл поста, я перевернул всё это в голове — и посыл в основном такой: "вам не нужно обновлять свои серверы". Именно это сказал бы человек с работающим эксплойтом. Или это просто шум в интернете.
- hn773746483
Социальные сети и "эксперты по кибербезопасности" сыграли в этом большую роль. Такие вещи, как "ЕС ЗАЯВЛЯЕТ, ЧТО ЭТО СРОЧНАЯ УЯЗВИМОСТЬ", и даже премьер-министр Японии с ночным экстренным обращением. Они ссылаются на посты "экспертов" в соцсетях о первоначальном бюллетене, в то время как те самые так называемые эксперты делятся стратегиями смягчения последствий из выдачи AI-поиска Google. Ни у одной из этих организаций или органов не было никаких деталей, кроме того, что было в бюллетенях и соцсетях. (например, "CVSS 10, это плохо!!")
Мне это кажется скорее похожим на broadpwn — технически серьёзно, широкий охват (миллионы iPhone), но никогда не станет универсальной кнопкой PWN.
Даже в эпоху AI, я не думаю, что это будет в дальнейшем превращено в оружие так, как Eternalblue... но я не тот парень из соцсетей по кибербезу с 15000 подписчиков, так что не принимайте мои слова за чистую монету ;)
- tibbar
Две вещи могут быть правдой одновременно: это реальная эксплуатируемая CVE 10, и её достаточно сложно сконструировать, чтобы вам понадобился хороший стенд + процесс верификации, чтобы ваша LLM не жульничала. Так что эксплойт может быть нелегко построить, но на самом деле он не требует искусственных настроек, которые подразумевал OP.
> Что мы продемонстрировали
> Pre-authentication RCE на WordPress, Drupal и Joomla
- nemothekid
Для меня странным было то, что не было никаких разборов того, как на самом деле работала уязвимость. Действительно кажется, что многие люди сказали "Claude нашёл баг, и Claude говорит, что это опасно", но никто на самом деле не проверил, насколько она реально эксплуатируема? Не то чтобы это стоило игнорировать, но по сравнению с Heartbleed (где эксплойты приходилось писать вручную) активных PoC гораздо меньше.
- apexalpha
Это было абсолютно эксплуатируемо. Тот факт, что существует 1000 неработающих PoC, не отменяет тот один, который работает.
Конечно, может, и не на ванильной установке, но большинство людей не устанавливают Php, они используют готовый контейнер или платформу, работающую на Php под капотом.
Вчера я просто перестал быть уверенным в безопасности, а данные в моей базе данных достаточно важны, чтобы уйти в офлайн на несколько часов.
- kgeist
Я запустил сегодня 2 PoC с GitHub: один действительно ожидал, что Local File Inclusion (LFI) уже присутствует (так что это просто LFI с лишними шагами), а другой вообще не работал из коробки без некоторых модификаций (хотя я использовал те же Docker-образы и всё такое). Второй PoC в конце концов вызвал реальный баг stale write, но он не продемонстрировал фактический RCE; он просто вызвал stale write. И тогда я задумался: это что, первый раз, когда в среде выполнения PHP вообще был баг повреждения памяти? Сомневаюсь (я помню, несколько лет назад у нас были случайные падения в продакшене под высокой нагрузкой из-за бага в opcache). И если это не первый баг повреждения памяти в среде выполнения PHP, почему его провозглашают худшей уязвимостью за годы?
- nickysielicki
Docker-образы от Wordpress, joomla и drupal все были эксплуатируемы.
- rectang
Согласно "Today's PHP Security Release, and How We're Strengthening PHP Security", обсуждаемому на https://news.ycombinator.com/item?id=50182987
* Относительно одной CVE: "Remote code execution также был подтверждён на PHP-FPM через пути кода на уровне приложения."
* Относительно другой CVE: "Были подтверждены use-after-free и падение воркера, и сообщавший продемонстрировал remote code execution против реального приложения, работающего на Apache с mod_php."
Поскольку эти эксплойты существуют, я ожидаю, что LLM скоро их воспроизведут.
- easterncalculus
Связанное видео LiveOverflow о фейковых эксплойтах, гуляющих вокруг https://www.youtube.com/watch?v=7CiZmq2llDg
Тем не менее, OP по сути полон дерьма. Это абсолютно эксплуатируемо, и люди просто будут предполагать платформу и ABI и распылять это по интернету, особенно надеясь на mod_php.
- 0x1F8B
Если они так уверены, что это не эксплуатируемо, этому человеку следует поднять очень простой сервер nginx с php-fpm, работающий на уязвимой версии PHP, и пригласить людей эксплуатировать его.