В PHP-FPM, менеджере процессов FastCGI, входящем в основную поставку PHP начиная с ветки 5.3, выявлена критическая уязвимость CVE-2021-21703, дающая возможность непривилегированному пользователю хостинга выполнить код с правами root. Проблема проявляется на серверах, использующих для организации запуска PHP-скриптов PHP-FPM, обычно применяемый в связке с Nginx. Выявившие проблему исследователи смогли подготовить рабочий прототип эксплоита...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56055
А я говорил, ставьте Apache2!
Там таких новостей еще более
именно такая ровно одна (в смысле, об ту же проблему)
А вот да, костылинг костылей в виде FPM такой костылинг.
Просто кто-то не осилил парсинг в свое время HTTP и изобрел целый зоопарк этих CGI протоколов
Теперь даже стыдно на это все смотреть - когда в любом Golang, Java, Ruby реалзованы полноценные асинхронные сервера с бешеной производительностьюС другой стороны популярность и шаблонность всегда удобнее и проще - много специаистов можно найти
https://reactphp.org/
А я говорил, не позволяйте запускать произвольный код!
>Примечательно, что разработчики PHP были уведомлены о проблеме ещё в мае, но не спешили с подготовкой исправления.Интересно чего они ждали?
хорошо хоть за уязвимость восприняли :)
После того как визг подняли и признали
Им некогда, они смузи фичи пилят.
Ни хрена не смузи. В 8.1 будут Fibers - это просто очешуенчик.
"очешуенчик" - wtf ОнаниZм?
С дивана долго поднимались
А чего ждать от мёртвого языка-то?
Живее всех живых строят и строят из этого говна и палок сайты и сегодня
Плнятное дело что доверить строительство ком то на пионерском языке это страшно
И надо еще обладать опредеелнными уровнем развития что бы понять что тебе сделали
с другой стороны кто не первый год в отрасли (всякие там аутсорсеры) те то знают
кому и что предлагать и за какие деньги - так что язык удел малого бзнеса
там ему и место
там эксплойт довольно нетривиален и негарантированно сработает (в идеале надо чтоб на сервере ты был единственным клиентом). Причем в любом случае требует возможности исполнять php код (что, в свете всяких eval и нескучных форматов файлов, исполняемых при попытке проверить существование, конечно, тоже не бином ньютона), т.е. это именно локальная уязвимость. А если у вас на сервере где исполняется пехепе есть еще чего взять кроме самого пехепе именно от того юзера которым он и запущен - то у меня для вас хреновая новость...Поэтому исправлять полезли, когда авторы пригрозили выпустить его in the wild, предварительно раскошелившись на детальное описание как эту багофичу таки можно поэксплойтить.
То есть визгу на самом деле было больше чем проблема заслуживает, но таки все же - дырень.
Надо переписать на сами знаете чем!
А ещё эксплуатация может быть осложнена изоляцией в контейнере или подсистемой безопасности, типа SELinux или AppArmor.
Ещё один пример того, что "должно работать" и "работает" - это не одно и тоже.
Компилируется значит работает (с)
>Основной процесс PHP-FPM, координирующий работу, запускается с правами rootЭто очень умное решение.
это юникс, тебе не понять, вчерародившийся.
Есть варианты как еще забиндить порт ниже 1024 и запускать чайлдов под другим юзером?
Обязательно расскажи.
Чта? В 99.99% случаев он работает на той же машине, что и NGINX, с которым они общаются либо через локальный сокет, либо через localhost:9000. Т.е. ему привилегированные порты в принципе не нужны.
Есть: CAP_NET_BIND_SERVICE. Насчет ограничения setuid/setgid с ходу не понял, надо разбираться. "Наихудший" вариант: разрешать неограниченный setuid, но зарубленный доступ ко всему через эти же capabilities.Начать можно с "Linux Capabilities in a nutshell", но лучше с английского языка и системного подхода к обучению.
Вовремя я избавился от php на своём личном сервере.
Лучше сразу от сервера. Нет сервера - нет уязвимостей.
И чем теперь пробавляемся?
А термин "увизгвимость" в html title страницы - это редактор так прикололся?
Это опеннет написан на перле. Старое не отредактированное значение всегда остаётся в заголовке страницы.
Задумался над тем, что когда-нибудь на Opennet появится (а может уже была) новость про уязвимость, через которую можно будет сломать его самого :) С подробным разъяснением и ссылкой на эксплойты. Хорошее оформление новости это не всегда хорошо :)
> Это опеннет написан на перле. Старое не отредактированное значение всегда остаётся в заголовке страницы.И при чем тут Perl ?
действительно. о мертвых либо хорошо, либо вообще никак.
Кому-то видимо особо нравятся свиньи.
Мне нравятся и что здесь плохого ?
Свиньи они миленькие когда маленькие, у тебя есть ручные свинки? (а ещё я люблю бекон и сало, кстати)
> я люблю бекон и салоСами-то как думаете - который Вы по счёту в такой шутке в мой адрес ? (подсказка - в числе уже больше четырёх нулей) !
:))))
>> я люблю бекон и сало
> Сами-то как думаете - который Вы по счёту в такой шутке в мой адрес ?А про Укpaинy кто-то уже шутил?
> А про Укpaинy кто-то уже шутил?всего лишь число с тремя нулями на конце - место в очереди :)))
> А термин "увизгвимость" в html title страницы - это редактор так прикололся?См под новостью: "Наводку на новость прислал пох."
ну я ж нечаянно...
Вот кто-кто, а вот конкретно ты мог и специально)
Вообще шанс эксплуатации этого дела околонулевой - надо пробить код (кто-то юзает FPM для untrusted code? ссзб), дальше надо трахаться с пробитием sandbox, дальше надо трахаться с тем, чтобы выйти на rce...Но тем не менее дыра злобно злая, хорошо что таки заткнули.
Ну в нескучном язычке, способном выполнить файл при попытке проверить его существование - таки это не нерешаемая задача. То есть эксплойт придется переделывать под конкретный кривой плагин конкретной супер-cms, но в принципе почти у каждого что-то такое можно найти, если хорошо поискать.Т.е. жить с такой дырой все же не стоит.
Для этого, правда, тот файл надо ещё загрузить, да так, чтобы с нужным расширением, и при проверке существования надо phar:// в начало имени подставить, ну да ладно. Тут проблема не в бобине, короче.
У этих ребят до сих пор eval()'ы в коде, чего вы от них хотели-то? Там завтра файл будет выполняться без существования, и никто не удивится.
(мысль по древу к тому, что PHP тут вообще сбоку пришёлся, дай им баш - так они и там уязвимость сделают)
баш - это вот та самая фигня, которая по нажатию tab исполняла внезапно код? Ну да, ну да...
Это по всяким шаредам типа GoDaddy может ударить.
FPM на шаредах - это редкое извращение.
И да, плять, я только что собрал 7.3.31 для проекта с FPM... Теперь надо собирать и тестить 7.3.32. Хорошо, что в прод ещё не ушло, притормозить не поздно.
нам бы ваши проблемы (исправляет .14 на .25)
да ни на что не повлияет, понятно что не есть это хорошо, но ничего реально критичного не произойдет, если это не шареный хостинг (но эти ССЗБ, если даже на дешманский VPS денег жмут)ну получил ты рута и что? в твоем php приложении крутится какой-то вредоносный код? нет... т.е. ты от рута ничего не сделал плохого, да это чревато в совокупности с другими дырами, но не более.
повышение локальных привелегий при наличии возможности выполнять любой код можно всегда попытаться осуществить с использованием row-hammer, а большинство проектов ECC память не используют, даже с Xeon процессорами, нонсенс, но факт (я посмотрел сервера доступные на аукционах, т.е. таких еще тысячами используется по всему миру), исключение составляют большие сервера с регистровой памятью, инстансы по 300+ вечнозеленых.
в общем как бы очень плохо, но несмертельно само по себе
На шаредах FPM - это угрё... утопи... нонсенс в общем :D
Насчёт ECC яхз, ECC память стоит не сильно дороже обычной по факту ныне.
> На шаредах FPM - это угрё... утопи... нонсенс в общем :D
> Насчёт ECC яхз, ECC память стоит не сильно дороже обычной по факту
> ныне.так они в новости пишут что с какой-то версии это часть PHP, а не просто отдельный компонент
> Уязвимость проявляется начиная с версии PHP 5.3.7, в которую был интегрирован PHP-FPM.
--
если регистровая так еще и дешевле, больше цена зависит от размера модуля, сильно крупные модули сильно дороже даже регистровые
но суть это не меняем, установка ECC в дедикейтед всё еще опция у многих ISP
На самом деле отдельный бинарник.
Забавно - в комментах пишут про мертвый язык или нескучный язык, а уязвимость в fpm_children.c
Уязвимость вызвана сохранением указателей в область разделяемой памяти (scoreboard), применяемой для организации взаимодействия между дочерним и родительским процессом PHP-FPM.Общая память к языку программирования не имеет отношения.
> Основные дистрибутивы выпустили обновления пакетов с устранением уязвимостиу RHEL статус CVE - New. Нифига они не выпустили. Ещё конь не валялся...
А кто мешает запускать php-fpm не под root-ом?name user
php-fpm php-fpm(not root)
|- php-fpm php-fpm(not root)
|- php-fpm php-fpm(not root)
У сабжа одна из ключевых фич - запуск рабочих процессов от других пользователей (ability to start workers with different uid/gid/chroot/environment), для нее нужны права рут.
В systemd возможно запустить php-fpm(main process) не от root, также включить всякую там защиту и т.д. Просто надо научиться читать документацию. Порты в firewall перенаправить выше 1000, также nginx должен работать под своим user-ом и не иметь доступ даже на чтение php файлов. Нужно понять, что бесплатно никто не даст гарантии безопасности, именно сейчас, может в будущем люди станут мудрее..........
Дякую, я й не знав, що так можна
Лень мешает. Люди настолько обленились, что хотят безопасности по дефолту. БД открыта наружу - виноват не админ сервера, а разработчик, который не делает по-умолчанию бинд на локалхост. Так же и тут.
Эпоха докера еще больше развратила людей. Бездумно ставят дефолтный образ и не видят в этом проблемы.
Пойти, что ли, выполнить код с правами root из-под непривилегированного пользователя на хостинге... Хотя, кого я хакаю -- я сам себе хостер и мне нахрен не вср*лась эта уязвимость.
На хостингах обычно нет FPM, забудьте.
> На хостингах обычно нет FPM, забудьте.Обычно на моём хостинге есть PHP-FPM, ибо я сам его туда поставил.
А, ну сочувствую.
В systemd возможно запустить php-fpm(main process) не от root, также включить всякую там защиту и т.д. Просто надо научиться читать документацию. Порты в firewall перенаправить выше 1000, также nginx должен работать под своим user-ом и не иметь доступ даже на чтение php файлов. Нужно понять, что бесплатно никто не даст гарантии безопасности, именно сейчас, может в будущем люди станут мудрее..........