Не стесняйтесь править новость, ну или написать свою, чукча не писатель. Например вся инфа относительно не-deb систем тут весьма сомнительная, пусть компетентные товарищи уточнят.

На сколько я понимаю уязвимость можно обойти изменив владельца директории /var/log/nginx. А ещё можно не запускать веборешето от пользователя www-data, а использовать для этого отдельного пользователя (пользователей). Я так и делаю, чего и вам желаю.

ХЗ о чем речь.

$ cat /etc/os-release | grep VERSION

VERSION_ID=«8»

VERSION=«8 (jessie)»

$ ls -al /var/log/ | grep nginx

drwxr-xr-x 2 root root 24K ноя 17 06:25 nginx

Как я понял там уязвимость не в nginx, а в '/etc/logrotate.d/nginx'

Нет, там уязвимость именно в правах на файлы, logrotate используется для пересоздания этих файлов.

With SELinux enforcing, it may still be possible for an attacker to redirect nginx's access.log output to another file labelled with httpd_log_t, but the consequences of such an attack are minimal.

Помница мне кото-то тут объяснял что MAC (SELinux) не нужен и юниксовые права и так рулят nginx не читает ssl key (комментарий). В студию приглашается Legioner.

Хо-хо, зато понятно, что там с не-дебианом :-)

избавиться от привычки отключать selinux - задача не из простых

Долой хипстоподелие, апач наше фсё!

Так и так понятно, CLOSED WONTFIX, там написано же.

Вообще это дистро- и сайто-специфичная атака через гипотетическое уязвимое веб-приложение или гипотетическую уязвимость в nginx. Если, как сказано в новости, "В nginx обнаружена уязвимость" то где тогда ссылка на баг в самом проекте nginx?

Предлагаю исправить сиё недоразумение на "Локальное повышение привелегий в Debian". (Спорить с "локальным" не возьмусь.)

как минимум Debian 8

Почему именно Debian 8? Предыдущая версия Debian-а разве не попадает под описание?

Вообще это дистро- и сайто-специфичная атака через гипотетическое уязвимое веб-приложение или гипотетическую уязвимость в nginx.

Либо вполне реальная локальная атака с повышением привилегий. То, что она может использоваться в т.ч. и удалённо через веб-приложение, достаточно дырявое для предоставления локального шелла с неадминистраторскими правами — так все локальные уязвимости такие.

Спасибо, с локальными и удалёнными понятно, а новость можно исправить? Это проблема с дебианом с правами на /var/log/nginx/ и отсутствием MAC. Зачем тень-то на nginx кидать.

привелегий

Новый химический элемент синтезировали?

Это проблема с дебианом с правами на /var/log/nginx/

А эти права дебианом придуманы, да? :-)

и отсутствием MAC.

И тут тоже кругом nginx не виноват.

ПривИлегий!!!

Как можно было пропустить новость с таким заголовком??

А эти права дебианом придуманы, да? :-)

Конечно.

https://anonscm.debian.org/cgit/collab-maint/nginx.git/commit/?id=333595dc838...
Там же и дебиановский "фикс" найдёте. Так исправлять будем или нет?

и отсутствием MAC.

И тут тоже кругом nginx не виноват.

Естественно.

Как можно было пропустить новость с таким заголовком?

Автор локально повысил привелегии, и хакнул модератора.

Так исправлять будем или нет?

Нет:

Уязвимости подвержены как минимум Debian 8, Ubuntu 14.04, Ubuntu 16.04, Ubuntu 16.10, RHEL и Fedora <…>, openSUSE.

Нет

Тяжёлый случай. Ссылку на баг в системе отслеживания ошибок проекта nginx или новость 4.2 (как минимум заголовок - точно).

Где ссылка на этот баг в trac.nginx.org если это баг nginx ?

Или это проблема криворуких мантейнеров в конкретных дистрибутивах?

Где ссылка на этот баг в trac.nginx.org если это баг nginx ?

да это просто триллер какой-то
ждем официального опровержения

Нет, в oldstable всё спокойно, там права кошерные. А вот в testing решето имеется, и фикс пока не выпустили.

А эти права дебианом придуманы, да? :-)

А разве нет? По идее такие директории создаёт пакетный менеджер при установке пакета, и руководствуется он информацией из пакета которою задаёт мейтейнер пакета. Или нет?
В общем Дебиановци конечно накосячили, как и красношапочники (SELinux не оправдание решета), вопрос только в том нужно-ли ставить к той-же стенке кого-то из nginx inc.

Я не очень понял как именно работает эта уязвимость, а это вообще нормально что манипулируя файлом в который пишет процесс можно заставить этот процесс выполнить произвольный код? Или там дело в том что можно заставить nginx писать логи в произвольный файл с правами рута и это каким-то образом позволяет поднять привилегии?

и руководствуется он информацией из пакета которою задаёт мейтейнер пакета.

А разработчики не причём? :-) Там же явно написано в описании, что nginx создаёт файл с определёнными правами.

В общем Дебиановци конечно накосячили, как и красношапочники (SELinux не оправдание решета), вопрос только в том нужно-ли ставить к той-же стенке кого-то из nginx inc.

Если тебе интересно моё мнение, нужно ставить к стенке всех тех, кто придумал систему глобальных репозитариев с майнтейнерами, из-за чего куча народа создают баги пакетирования, вносят свои исправления и занимаются другим сизифовым трудом (это не намёк :-)).

Если бы в мире был единственный пакет nginx, подходящий под все линуксы, все проблемы решались бы разработчиками nginx. Или разработчиками форка nginx в случае упоротости первых. А так мы имеем то, что имеем.

Но моё мнение здесь никого не волнует, и я считаю, что вопрос «кто виноват» тут не стоит, не стоит и вопрос «что делать», поскольку вон редхатовцы вообще решили не патчить, а дебиановцы/убунтушники уже пропатчили.

Или там дело в том что можно заставить nginx писать логи в произвольный файл с правами рута и это каким-то образом позволяет поднять привилегии?

Второе. Можно заставить nginx создать пустой файл с правами рута, записать в него свои данные и подсунуть его ld preloader-у. В обычных условиях ты не имеешь права создать файл в /etc и записать в него что-то.

избавиться от привычки не осиливать selinux - задача не из простых

починил

На месте RedHat я бы уже привязал systemd к selinux. Хейтеры всё равно gonna hate, а так хоть кому-то пришлось бы изучать :-)

И снова серьезная уязвимость (и плевать что локальная), из-за того, что кто-то не досмотрел...

# Allow local admin to override
     if ! dpkg-statoverride --list "$logdir" >/dev/null; then
-      chown www-data:adm $logdir
-      chmod 0750 $logdir
+      chown root:adm $logdir
+      chmod 0755 $logdir
     fi

В песочницу, т.к. новые версиии не подвержены дыре, только некоторые старые версии. PS. 2016-11-15 nginx-1.11.6 mainline version has been released.

Пакет с репозитория nginx.org кстати не подвержен, потому-что там было chmod 640 изначально.

локальному злоумышленнику с правами www-data

Откуда ему взяться-то?

nginx (1.6.2-5+deb8u3) jessie-security; urgency=high

[ Christos Trochalakis ] * debian/nginx-common.postinst: + CVE-2016-1247: Secure log file handling (owner & permissions) against privilege escalation attacks. /var/log/nginx is now owned by root:adm. Thanks ro Dawid Golunski for the report. Changing /var/log/nginx permissions effectively reopens #701112, since log files can be world-readable. This is a trade-off until a better log opening solution is implemented upstream (trac:376).

 — Christos Trochalakis <yatiohi@ideopolis.gr> Tue, 04 Oct 2016 15:20:33 +0300

Tue, 04 Oct 2016 Tue, 04 Oct 04 Oct

Из любого дырявого веб-приложения работающего под www-data. php-fpm из коробки запускает пулы под эти пользователем, apache вроде тоже под ним работает.

ШЕРЕТО!

ШЕРЕТО!

# sudo -u www-data touch /var/log/nginx/test
touch: cannot touch `/var/log/nginx/test': Permission denied

Debian 7

Да, oldstable безопасносте. Шерето от восьмёрочки и выше. Для тестинга вот до сих пор фиксы не выкатили.

MAC (SELinux) не нужен

Если история чему-то и учит, так это тому, что класс программ смотрящих в сеть (для юзера это емылклиент и браузер), всегда был средством распространения самых эпических эпидемий ever.

На месте RedHat я бы уже привязал systemd к selinux

Но в других системах же AppArmor, поэтому совсем гвоздями не надо.

А что эффективнее, а что менее геморно в настройке SELinux или AppArmor?

В случае сферического GNU/Linux в вакууме AppArmor проще (можно написать правила только для нужных бинарей), SELinux предполагает более комплексный подход. Но в Шапке, Центе и Федоре SElinux настроен из коробки и нужно только расставлять метки на тех файлах которые ты сам создаёшь или перетягивешь откуда-то.

https://forum.drweb.com/index.php?showtopic=326052

Drink tea, juice, coffee and water. :-)

уязвимости присвоен низкий приоритет, так как стандартные политики SELinux ограничивают возможности её эксплуатации или делают эксплуатацию невозможной

selinux - это то, что блокирует сетевые запросы с локалхоста на локалхост, и что надо отключать чтобы хоть что-то нормально работало. низкий приоритет, угу, понятненько.

centos + selinux менее геморно

садись, два.

ты прав

таки займусь миграцией с федоры на что-то приличное. они похоже задались целью собрать в дистрибутиве всё дерьмо которое только могут придумать альтернативно-одарённые «инженеры» и «дизайнеры». ещё и уязвимости не исправляют ссылаясь на какое-то своё дерьмецо которое мешает нормальной работе. это провал, братюнь. хотя с их точки зрения, это наверное «перемога». ну, перемоги - они всегда такие.

На сколько я понимаю уязвимость можно обойти изменив владельца директории /var/log/nginx. А ещё можно не запускать веборешето от пользователя www-data, а использовать для этого отдельного пользователя (пользователей). Я так и делаю, чего и вам желаю.

nobody?

P.S. 48 комментариев против 541 у новости про ReactOS. Как-то неактуально, что пол инета накроется, по сравнению с очередной переделкой вайна (утрирую).

slow update, хотя скорей всего пользователи сабжа все-таки в курсу

Update 11.01.2017: Gentoo and its nginx packages were also found affected by this vulnerability: https://security.gentoo.org/glsa/201701-22 nginx < 1.10.2-r3