Php fpm not root
Живее всех живых строят и строят из этого говна и палок сайты и сегодня
Плнятное дело что доверить строительство ком то на пионерском языке это страшно
И надо еще обладать опредеелнными уровнем развития что бы понять что тебе сделали
с другой стороны кто не первый год в отрасли (всякие там аутсорсеры) те то знают
кому и что предлагать и за какие деньги — так что язык удел малого бзнеса
там ему и место
там эксплойт довольно нетривиален и негарантированно сработает (в идеале надо чтоб на сервере ты был единственным клиентом). Причем в любом случае требует возможности исполнять 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», но лучше с английского языка и системного подхода к обучению.
Это опеннет написан на перле. Старое не отредактированное значение всегда остаётся в заголовке страницы.
Задумался над тем, что когда-нибудь на Opennet появится (а может уже была) новость про уязвимость, через которую можно будет сломать его самого 🙂 С подробным разъяснением и ссылкой на эксплойты. Хорошее оформление новости это не всегда хорошо 🙂
> Это опеннет написан на перле. Старое не отредактированное значение всегда остаётся в заголовке страницы.
И при чем тут Perl ?
Свиньи они миленькие когда маленькие, у тебя есть ручные свинки? (а ещё я люблю бекон и сало, кстати)
> я люблю бекон и сало
Сами-то как думаете — который Вы по счёту в такой шутке в мой адрес ? (подсказка — в числе уже больше четырёх нулей) !
:))))
>> я люблю бекон и сало
> Сами-то как думаете — который Вы по счёту в такой шутке в мой адрес ?А про Укpaинy кто-то уже шутил?
> А про Укpaинy кто-то уже шутил?
всего лишь число с тремя нулями на конце — место в очереди :)))
> А термин «увизгвимость» в html title страницы — это редактор так прикололся?
См под новостью: «Наводку на новость прислал пох.»
Вообще шанс эксплуатации этого дела околонулевой — надо пробить код (кто-то юзает FPM для untrusted code? ссзб), дальше надо трахаться с пробитием sandbox, дальше надо трахаться с тем, чтобы выйти на rce.
Но тем не менее дыра злобно злая, хорошо что таки заткнули.
Ну в нескучном язычке, способном выполнить файл при попытке проверить его существование — таки это не нерешаемая задача. То есть эксплойт придется переделывать под конкретный кривой плагин конкретной супер-cms, но в принципе почти у каждого что-то такое можно найти, если хорошо поискать.
Т.е. жить с такой дырой все же не стоит.
Для этого, правда, тот файл надо ещё загрузить, да так, чтобы с нужным расширением, и при проверке существования надо phar:// в начало имени подставить, ну да ладно. Тут проблема не в бобине, короче.
У этих ребят до сих пор eval()’ы в коде, чего вы от них хотели-то? Там завтра файл будет выполняться без существования, и никто не удивится.
(мысль по древу к тому, что PHP тут вообще сбоку пришёлся, дай им баш — так они и там уязвимость сделают)
И да, плять, я только что собрал 7.3.31 для проекта с FPM. Теперь надо собирать и тестить 7.3.32. Хорошо, что в прод ещё не ушло, притормозить не поздно.
да ни на что не повлияет, понятно что не есть это хорошо, но ничего реально критичного не произойдет, если это не шареный хостинг (но эти ССЗБ, если даже на дешманский VPS денег жмут)
ну получил ты рута и что? в твоем php приложении крутится какой-то вредоносный код? нет. т.е. ты от рута ничего не сделал плохого, да это чревато в совокупности с другими дырами, но не более.
повышение локальных привелегий при наличии возможности выполнять любой код можно всегда попытаться осуществить с использованием row-hammer, а большинство проектов ECC память не используют, даже с Xeon процессорами, нонсенс, но факт (я посмотрел сервера доступные на аукционах, т.е. таких еще тысячами используется по всему миру), исключение составляют большие сервера с регистровой памятью, инстансы по 300+ вечнозеленых.
в общем как бы очень плохо, но несмертельно само по себе
На шаредах FPM — это угрё. утопи. нонсенс в общем 😀
Насчёт ECC яхз, ECC память стоит не сильно дороже обычной по факту ныне.
> На шаредах FPM — это угрё. утопи. нонсенс в общем 😀
> Насчёт ECC яхз, ECC память стоит не сильно дороже обычной по факту
> ныне.так они в новости пишут что с какой-то версии это часть PHP, а не просто отдельный компонент
> Уязвимость проявляется начиная с версии PHP 5.3.7, в которую был интегрирован PHP-FPM.
—
если регистровая так еще и дешевле, больше цена зависит от размера модуля, сильно крупные модули сильно дороже даже регистровые
но суть это не меняем, установка ECC в дедикейтед всё еще опция у многих ISP
Уязвимость вызвана сохранением указателей в область разделяемой памяти (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, забудьте.
Обычно на моём хостинге есть PHP-FPM, ибо я сам его туда поставил.
В systemd возможно запустить php-fpm(main process) не от root, также включить всякую там защиту и т.д. Просто надо научиться читать документацию. Порты в firewall перенаправить выше 1000, также nginx должен работать под своим user-ом и не иметь доступ даже на чтение php файлов. Нужно понять, что бесплатно никто не даст гарантии безопасности, именно сейчас, может в будущем люди станут мудрее.
Saved searches
Use saved searches to filter your results more quickly
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run php:fpm as non-root #70
Run php:fpm as non-root #70
Comments
Unlike the php:apache image where Apache drops root privileges to www-data before running any PHP code, the php:fpm image is still running as root .
Since it doesn’t actually need root privileges, it would probably be best if php:fpm ran PHP code as a non- root user. In the case of php:fpm , it seems like it should work fine to use a USER fpm without pulling in gosu or anything like that.
The text was updated successfully, but these errors were encountered:
Looks like it already runs as www-data . Sorry for the false alarm!
Actually, I would rather reopen this as the master process still runs as root:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.1 174384 18104 ? Ss 11:02 0:00 php-fpm: master process (/usr/local/etc/php-fpm.conf) www-data 9 0.0 0.1 185184 24516 ? S 11:02 0:00 php-fpm: pool www www-data 10 0.0 0.1 190832 29812 ? S 11:02 0:00 php-fpm: pool www @sagikazarmark as far as I can tell that is identical to many installs on non-container systems running apache/php or fpm:
# from my system with host installed apache/php $ ps aux | grep apache root 2814 0.0 0.0 267996 16348 ? Ss Jul12 1:13 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 3952 0.0 0.0 269956 18288 ? S Aug01 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 3970 0.0 0.0 270056 17640 ? S Aug01 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 8069 0.0 0.0 197788 7088 ? S Jul31 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 8172 0.0 0.0 270344 18732 ? S Jul31 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 8173 0.0 0.0 269916 17868 ? S Jul31 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 8175 0.0 0.0 269888 17652 ? S Jul31 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 8176 0.0 0.0 269964 17744 ? S Jul31 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 11306 0.0 0.0 270084 17584 ? S Aug03 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 16977 0.0 0.0 269120 16780 ? S Aug02 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 24479 0.0 0.0 269572 17996 ? S Aug03 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start apache 27083 0.0 0.0 270056 17764 ? S Aug02 0:00 /usr/sbin/apache2 -D INFO -D LANGUAGE -D PHP5 -D PROXY -d /usr/lib64/apache2 -f /etc/apache2/httpd.conf -k start and can be overcome by using —user www-data , if full-coverage is necessary:
$ dockr run -it --rm --user www-data php:fpm [04-Aug-2016 18:09:04] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root [04-Aug-2016 18:09:04] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root [04-Aug-2016 18:09:04] NOTICE: fpm is running, pid 1 [04-Aug-2016 18:09:04] NOTICE: ready to handle connections
Indeed. Actually I am not sure about this, because on side there is the security issue of running root inside the container, on the other side there is what you say. So what’s the correct way of doing this? I read about security issues and recommendations to run processes with non-root UID.
I think it depends wholly on your use case and your threat model. For most typical use-cases, the existing behavior should be sufficient (especially if combined with user namespaces on the daemon, thus making root in the container non-root on the host). The extra paranoid will likely want to run as some arbitrary UID that isn’t consistent, which should also be possible via «—user» (assuming file permissions are appropriately set to handle the change as well).