Опубликованы (http://openwall.com/lists/oss-security/2016/11/16/2) подробности и эксплоит для уязвимости (CVE-2016-1247 (https://security-tracker.debian.org/tracker/CVE-2016-1247)) в пакете с nginx, в конце октября устранённой в Debian (https://www.debian.org/security/2016/dsa-3701) и Ubuntu (https://www.ubuntu.com/usn/usn-3114-1/). Проблема специфична (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-P...) для deb-пакета nginx, не касается самого nginx, и может привести к выполнению кода с правами root при наличии у атакующего прав доступа "www-data" в системе.Проблема вызвана (https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-P...) некорректными настройками доступа к директории с логами web-сервера. Директория с логами /var/log/nginx имеет владельца "www-data", что позволяет пользователю с данными полномочиями произвольно манипулировать файлами в данной директории. При запуске или перезапуске nginx в лог добавляются записи от процесса с правами root. Периодически скрипт ротации логов меняет владельца файлов с логами на "www-data".
Локальный пользователь с правами www-data может создать в директории /var/log/nginx символическую ссылку вместо файла с логом "error.log". Таким образом, направив символическую ссылку "/var/log/nginx/error.log" на другой файл перед перезапуском nginx, можно изменить любой файл в системе. Перезапуск nginx по сигналу USR1 осуществляется скриптом ротации логов, который по умолчанию вызывается из cron.daily каждый день в 6:25.
Для организации запуска кода с правами root в эксплоите осуществляется создание символической ссылки на файл /etc/ld.so.preload (/var/log/nginx/error.log -> /etc/ld.so.preload), который после перезапуска nginx будет создан, а после ротации лога получит владельца www-data, что позволит прописать в нём произвольную библиотеку атакующего, после чего библиотека будет активироваться при выполнении любого исполняемого файла, например, можно запустить suid root приложение /usr/bin/sudo.URL: http://openwall.com/lists/oss-security/2016/11/16/2
Новость: http://www.opennet.me/opennews/art.shtml?num=45515
>ротация логовКамон, сириусли? Зачем их хранить? Линковать на /dev/null, и все дела.
администратор локалхоста в чяте.
Перефразируя известный афоризм: есть администраторы, которые еще не хранят логи...
некоторые гоняют при помощи syslog
> некоторые гоняют при помощи syslogsyslog появился до вашего рождения и всех всем устраивал столько лет, сколько вам еще нет.
Во-первых, отучайся говорить за всех. Это плохая привычка.Во-вторых, если бы syslog всех всем устраивал, что не появилось бы пачка альтернатив.
В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева. Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку syslog в nginx?
> В-третьих, syslog совершенно не устраивает многих админов в хайлоаде, например Сысоева.
> Сам нагуглить осилишь, почему он столько времени не хотел добавлять поддержку
> syslog в nginx?Syslog - это понятие, обобщающее клиента, протокол и сервер.
Насколько я понял, Сысоева не устраивал протокол syslog из за возможной потери пакетов и загрузка syslog сервера (syslogd): http://www.lexa.ru/nginx-ru/msg17262.html
> Я тут имел несчастье наблюдать 130 сообщений в секунду через syslogd.
> Машинка, конечно, не первой мододости, 2x P3-700, но отжирать при этом 12%
> процессора только на чтение и запись сообщения - это слишком.Ну, во первых, с тех пор компьютеры стали чуть мощнее.
Во вторых syslogd - не тот инструмент, которым надо ловить логи веб сервера.
Тогда хотя бы можно было использовать syslog-ng.
А сейчас для этого есть отличные связки вида Logstash+ElasticSearch+Kibana, или Statsd+Graphite, которые отлично обрабатывают 10k rps.
Ну и на хайлоаде потеря пары пакетов не страшна, когда у тебя нагрузка 1к rps.Так что syslog на хайлоаде - вещь хорошая, только её нужно правильно приготовить.
Отправка логов по сети помогает разгрузить сервер - ему не нужно тратиться на дисковый I/O.
Опять дебиан отличился :) сначала OpenSSL, теперь ngnix...
Тоже мне, сравнил.
а что не так? и то и другое от кривых рук маинтейнера пакета. И учитывая распространенность дебиана - можно поспорить что уже ботнет поднялся..
Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему, не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся. Здесь же - не ssh, который есть вообще на любом сервере, а нгинкс, который может быть, а может и не быть.
Ну, на шаред-хостингах нгинкс обычно не может не быть - ради ускорения его непременно ставят перед тем, на чем крутятся клиентские сайты. Правда, при этом вход от имени www-data (пользователя, от имени которого работает nginx) по ssh может быть вовсе заблокирован. А что там себе наваляют в домашних папочках пользователи - будет проигнорировано.
думаю не опасно, если nginx и пхп на разных вирт серверах.
> по ssh может быть вовсе заблокирован.там пхп реверсный шел юзается, ссх там тока админская консоль чтоб запустить ротацию логов, в реале нуно ждать конца дня )
По умолчанию под пользователем www-data выполняются, например, php-скрипты.
На шаредах php-скрипты выполняются от имени юзеров.
А nginx, как я это понимаю - от имени пользователя, которому шелл вообще не требуется.
>>от имени пользователя, которому шелл вообще не требуется.ну и пхп не требуется, но это же не мешает выполнять system(),exec(),passthru() и т.д.
Удаленно зайти и выполнить описанные в статье действия - мешает.
> Удаленно зайти и выполнить описанные в статье действия - мешает.Вам же объясняют: любой локальный рут - это возможность поднятия ранее полученного удаленного юзера. Как правило удаленный рут получается цепочкой сплоитов.
Не понимаю - зачем нужна обсуждаемая уязвимость, если уже получен локальный рут?
В теме-то именно действия от имени пользователя, от которого запускается nginx.
Если под таким пользователем нет возможности зайти удаленно - эксплойт неприменим.
> Не понимаю - зачем нужна обсуждаемая уязвимость, если уже получен локальный рут?Издеваетесь что ли? Если хэккер получил удаленного www-data, то его возможности ограничены правами www-data. Вот тут то и приходит время обсуждаемой дыры.
Если же Вам охота обсудить возможности получения удаленного www-data, то это тема для отдельного треда.
Конкретно эта ветка и начинается с моего утверждения, что на шаредах пользователю, от имени которого запускается nginx, не нужна возможность удаленного входа. То есть он, при грамотной настройке - и не имеет такой возможности.
Доступ же простого юзера (с оплаченным тарифом) не дает доступа к nginx.
на видео видно как автор через якобы багу загружает на сервер реверсивный пхп шел вот вам и удалённо, нет смысла обсуждать как он получил реверсивный шелл ибо это выходит за рамки самой уязвимости, а суть уязвимости в эскалации привилегий, он с правами www-data в итоге получил права root-а.
Еще раз: если даже вы получили шелл с правами юзера шаред-хостинга - конкретно этот эксплойт вам не поможет поднять привилегии.
я чёт не понял смысла вашего предложения. Конкретно эксплоит выполнится, если у вас такой же дебиан с теми же правами на логи и ротатором, и в случае получения шелла от имени того пользователя (будь хоть ссх шелл или пхп без разницыыыыы) позволит повысить права до рута - ФАКТ!!!!
> Директория с логами /var/log/nginx имеет владельца "www-data", что позволяет пользователю с данными полномочиями произвольно манипулировать файлами в данной директории.А юзеры на шареде - это не тот пользователь www-data, от имени которого запускается nginx на сервере шаред-хостинга. И у нормального хостера такой пользователь вообще не будет иметь внешнего шелла, ибо незачем.
Вот и все.
> Ну, на шаред-хостингах нгинкс обычно не может не бытьЕсли у кого shared хостинг и логи нжинкса доступны всем подряд - как минимум это уже vuln поскольку атакующий может проводить наглейший data mining на ресурсах которые ему вообще не принадлежат, изучая чужих посетителей.
Более того - если атакующий может что-то менять под www-data он скорее всего может раздестроить к чертям все сайты и например редиректнуть всю толпу на свой сайт, допустим с малварью или какой там еще фэйковой формой логина гмыл/втентакля/кого там еще по вкусу.
Поэтому?..
> Угу, ботнет от локальной уязвимости. Которую ты от ремотной, судя по всему,
> не отличаешь. Хотя даже там, насколько я знаю, ботнет не поднялся.
> Здесь же - не ssh, который есть вообще на любом сервере,
> а нгинкс, который может быть, а может и не быть.а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру?
> а конфиг iptables/sshd нельзя поправить/заменить своим на время, используя эту дыру?Зачем? Если есть возможность добраться до этой дыры, то надо ставить реверс шелл. Ибо, насколько я понимаю, в файл, на который Вы сделаете ссылку, nginx будет гадить логами.
ЗЫ: напомните, что за "конфиг iptables"?
> nginx будет гадить логами.а суть в том, что сразу после сработки логротейта нджинкс не успеет нагадит в него, и эксплоит сразу же выполнит нужную ему команду ну как в примере сюидную какую нить.
Походу, ты вообще не понял, как работает эта уязвимость. Дело не в logrotate, а в nginx и не играет никакой роли, запишет ли он что-либо в лог.
> и то и другое от кривых рук маинтейнера пакета.Ну не совсем, изменение в OpenSSL одобрили сами авторы.
Каким боком Debian к сборке ngnix под DEB?
> Каким боком Debian к сборке ngnix под DEB?Угадайте с двух, нет, с трёх попыток. Третья -- на прочтение DSA-3701.
Казалось бы, что мешает использовать
deb http://nginx.org/packages/debian/ CODENAME nginx
или
deb http://nginx.org/packages/mainline/debian/ CODENAME nginx
?
Хотя мэйнтэйнерам, конечно, двойка.
В случае в дебианом там статично слинкована старая OpenSSL 1.0.1, которая не поддерживает ALPN для HTTP/2. Так что приходится собирать из исходников.
А вы на какой ветке (ветках)?
> Опять дебиан отличился :) сначала OpenSSL, теперь ngnix..еще стоит вспомнить exim в их исполнении ;)
exim стоит вспомнить безотносительно дебиана. Хотя что с его конфигаме делают в дебиане - это какой-то бесконечный ужас.
Это же самый стабильно-серверный дистрибутив. История с openssh туда же)
Сила мелочей, классный эффект. Не по теме а почему черепашка а не обезьяна с гранатой :D
А почему проблему видят в дебиане, а не в работе nginx с файлами логов? При получении сигнала USR1 он переоткрывает логи, создавая описанную проблему с симлинками. То есть единственное, в чем виноваты некоторые(к примеру в wheezy это не так) из debian дистров, так в том, что /var/log/nginx имеет владельца www-data. Однако ведь точно такая же проблема возникнет, если админ скажет nginx класть логи для виртуалхостов непосредственно в их каталоги, что весьма удобно и никаких предупреждений на этот счет в доке nginx нет.
Проблемы debian разработчиков nginx не колышат, это только их проблемы - мы лучше будем контрибутить FreeBSD и Ubuntu с RHEL и SUSE
Для танкистов повторяю, проблема не в debian, а в способе работы с логами в nginx. И проявится это может в любом другом дистре.
Из за ваших детских болезней костыли в софт никто добавлять не собирается, если майнтейнер малолетнее ……
Получается, другие каталоги в /var/log с не-root владельцем тоже потенциально уязвимы...
Зависит от того, как программа обрабатывает симлинки. В данном случае nginx создает файл, следуя по симлинке, и меняет ему владельца на своего пользователя. Но не весь софт так делает.
Проблема не ограничивается /var/log/*
Red Hat говорит что не проблема:https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1247
Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
И после этого ещё катят бочку на Debian, где дыру сразу закрыли.
В редхат nginx не поставку входит, если что. Только в epel. Это несколько другой уровень ответственности.А низкий приоритет потому, что selinux из коробки от этой уязвимости защищает.
Точно защищает? Проверял? А вот я взял образ centos 6 и проверил[root@Falcon /]# cd /var/log/nginx/
[root@Falcon nginx]# ls -al
total 8
drwx------ 2 nginx nginx 4096 Nov 18 17:18 .
drwxr-xr-x 3 root root 4096 Nov 18 17:18 ..
-rw-r--r-- 1 root root 0 Nov 18 17:18 access.log
-rw-r--r-- 1 root root 0 Nov 18 17:18 error.log
[root@Falcon nginx]# rm access.log
rm: remove regular empty file `access.log'? y
[root@Falcon nginx]# ln -s /etc/test access.log
[root@Falcon nginx]# kill -USR1 734
[root@Falcon nginx]# ls -al
total 8
drwx------ 2 nginx nginx 4096 Nov 18 17:20 .
drwxr-xr-x 3 root root 4096 Nov 18 17:18 ..
lrwxrwxrwx 1 root root 9 Nov 18 17:20 access.log -> /etc/test
-rw-r--r-- 1 nginx root 0 Nov 18 17:18 error.log
[root@Falcon nginx]# ls -al /etc/test
-rw-r--r-- 1 nginx root 0 Nov 18 17:21 /etc/test
[root@Falcon nginx]# cat /etc/issue
CentOS release 6.8 (Final)
Kernel \r on an \m
а центось это не рэдхэт)
> а центось это не рэдхэт)В данном контексте - они эквивалентны.
а что с selinux?
Эээ я прямо даже теряюсь. Вы слово "selinux" видите?Политика selinux по умолчанию targeted - она защищает конкретные демоны, для которых создана политика, а не произвольный программный код, запускаемый от пользователя (его тоже можно, но это требует сложного подхода и не разу ни из коробки).
От пользователя у вас получится сделать все, что угодно (ps -Z - можете убедиться, что вы в контексте unconfined_t). Из nginx'а, работающего в другом контексте у вас эти операции проделать не получится. В nginx будет ошибка, в audit-логе - событие AVC.
> Эээ я прямо даже теряюсь. Вы слово "selinux" видите?
> Политика selinux по умолчанию targeted - она защищает конкретные демоны, для которых
> создана политика…Эээ я прямо даже теряюсь. Вы это видили?:
Default SELinux policies on RHEL and Fedora protect against this flaw by limiting the files nginx's (uid 0) logging process can write to (httpd_log_t).
Only systems running with `setenforce 0` or running nginx unconfined are vulnerable to privilege escalation.
И так вопрос - selinux был включен?
Какое отношение то, что вы написали имеет к командам шелла, выполненным выше (которые предположительно что-то там должны показывать)? Если процесс nginx в тесте не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак.Запустите nginx и посмотрите на вывод команд ps auxZ|grep nginx и ps auxZ|grep $$ наконец...
> Если процесс nginx в тесте не фигурирует, selinux с targeted-политикой не вмешивается в процесс вообще никак.а какой процесс по вашему фигурирует тут?
> [root@Falcon nginx]# kill -USR1 734
Прямо детский сад.
зы. "selinux с targeted-политикой" следит и за пользовательскими процессами, by ex:
> SELinux is preventing /usr/lib64/firefox/plugin-container from sendto access on the unix_dgram_socket @nvidia9dc15530.
> а какой процесс по вашему фигурирует тут?bash, ls, ln, kill (впрочем, тк не /usr/bin/kill, тот же bash), cat. Сделайте на бинарники ls -lZ и убедитесь, что это unconfined_t
Но дело даже совсем не в этом. Даже если *был бы* контекст и selinux что-то им запрещал - это был бы *совершенно другой* контекст, чем у nginx (впрочем, в этом случае ls -Z не показал бы всей правды - нужно смотреть через selinuxexeccon, что во что может перейти, а что во что не может). Поэтому данный тест не имеет смысла по определению для выяснения вопроса "влияет selinux на nginx или нет". Если вы не верите умению читать политику selinux, реальный тест можно провести только из самого приложения. Ну или сделайте себе копию /bin/bash, через chcon поставьте на нее контекст как у nginx, запустите (убедитесь через ps -Z, что в нужном контексте) и оттуда уже делайте ваш эксперимент. Если вообще дадут запустить.
> зы. "selinux с targeted-политикой" следит и за пользовательскими процессами, by ex:
*фейспалм*
$ ls -lZ /usr/lib64/firefox/plugin-container
-rwxr-xr-x. 1 root root system_u:object_r:mozilla_plugin_exec_t:s0 279824 ноя 15 01:47 /usr/lib64/firefox/plugin-containerНу логично, что.
Конечно, selinux следит и за не-рутовыми процессами (которые формально пользовательские - пусть и не всегда того пользователя, который залогинен). Не надо придираться, я имел ввиду совсем не это. Когда вы дергаете из консоли утилиты общего назначения, ни на что из них политика не распространяется, вот и все. Несколько хитрых штук типа plugin-container являются исключениями, но это очень редкие случаи, да и помощи там от selinux с точки зрения практической безопасности не так много. Лично от меня сейчас в контексте, отличном от unconfined_t выполняются только Xorg и dbus-daemon.
>> а какой процесс по вашему фигурирует тут?
> killо боже! вы не знаете что делает "kill"??? посылает сигнал процессу nginx который в нужном контексте - это же очевидно!!!
«Управление nginx: USR1 переоткрытие лог-файлов»
зы2
> Когда вы дергаете из консоли утилиты общего назначения, ни на что из них политика не распространяетсясмотрим:
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xvinfo
-rwxr-xr-x. root root system_u:object_r:xserver_exec_t:s0 Xvnc
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xwininfo
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xxd
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xxkb
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xz
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 xzcat -> xz
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 xzcmp -> xzdiff
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xzdec
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xzdiff
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 xzegrep -> xzgrep
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 xzfgrep -> xzgrep
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xzgrep
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xzless
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 xzmore
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yacc
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yelp
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yes
lrwxrwxrwx. root root system_u:object_r:bin_t:s0 ypdomainname -> hostname
-rwxr-xr-x. root root system_u:object_r:rpm_exec_t:s0 yum
-rwxr-xr-x. root root system_u:object_r:rpm_exec_t:s0 yum-builddep
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yum-config-manager
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yum-debug-dump
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yum-debug-restore
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 yumdownloaderкак видете у всех есть своя политика! И можно даже подкрутить права для них :)
> о боже! вы не знаете что делает "kill"??? посылает сигнал процессу nginx который в нужном контексте - это же очевидно!!!
> «Управление nginx: USR1 переоткрытие лог-файлов»Ну тут уж прямо без комментариев. Вы новость вообще читали? В чем уязвимость, смотрели?
Из-за прав на каталог, принадлежащих nginx, можно сделать манипуляцию из кода, выполняющегося из под nginx с правами www-data (напр cgi и прочему).В редхате политика selinux БЛОКИРУЕТ данную возможность. Нельзя из под nginx ничего там делать. Только логгер с правами рута может туда что-то писать и что-то менять, а обычный код, выполняющийся из-под nginx с правами www-data - не может. Хотя по привилегиям возможно, как и в дебиане, но selinux блокирует.
Что вы пытаетесь показать этим бессмысленным тестом, создавая симлинк из-под рута, я не понимаю. Разумеется, selinux не распространяется на команду ln из рутового шелла. И дает вам это сделать. Но предполагаемый реальный вектор атаки - блокируется.
А kill тут вообще не при чем. Для вашего эксперимента с симлинком вы УЖЕ рут - да, имея права рута, можно подготовить систему так, чтобы эта "уязвимость" проявилась в nginx несмотря на selinux. Только это не имеет отношения к реальности, т.к. для демонстрации повышения привилегий вы выполняете злонамеренные действия из рута.
> как видете у всех есть своя политика! И можно даже подкрутить права для них :)
Если вы рут - можете вообще все, что угодно делать, крутите что хотите. Политика - ну откройте-таки доки по selinux и посмотрите, что такое bin_t и как это используется.. Если не понимаете - ну запустите любую из утилит выше (yes или там xz удобно, они сами не завершатся) и посмотрите ps'ом ее контекст во время выполнения.
> Что вы пытаетесь показать этим бессмысленным тестом,Вы точно уверенны что это был я??? я всего лишь спросил автора теста - был ли при этом selinux, а вы возбудились не по-детски. и нагородили при этом какую-то кашу.
Да неважно, кто. Я, кстати, тоже оригинальному автору писал, да что-то в моем комментарии вам не понравилось. И зачем вы пытаетесь доказать, что selinux имел какое-то отношение к тому тесту - когда даже при активной политике на nginx, защищающей от уязвимости, в текущем виде он не может продемонстрировать ровным счетом ничего - понять не могу! Вопрос "был ли там включен selinux" (думаю, ответ "да") просто нерелевантен, это ни на что не влияет.
Я мучую детей в школе.
Stax лучше бы ты сосал