LINUX.ORG.RU

Локальное повышение привилегий в nginx (CVE-2016-1247)

 ,


3

4

В nginx обнаружена уязвимость, позволяющая локальному злоумышленнику с правами www-data повысить привилегии до root.

Уязвимости подвержены как минимум Debian 8, Ubuntu 14.04, Ubuntu 16.04, Ubuntu 16.10, RHEL и Fedora (уязвимости присвоен низкий приоритет, так как стандартные политики SELinux ограничивают возможности её эксплуатации или делают эксплуатацию невозможной), openSUSE.

Исправляющие уязвимость обновления выпущены для Debian и Ubuntu, информация о других дистрибутивах требует уточнения.

Доступен эксплоит.

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: sudopacman (всего исправлений: 2)

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

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

MrClon ★★★★★
() автор топика

ХЗ о чем речь.

$ 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

anonymous
()
Ответ на: комментарий от Deleted

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

Aceler ★★★★★
()

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.

d_a ★★★★★
()

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

TooPar
()
Ответ на: комментарий от Aceler

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

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

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

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)

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

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

pacify ★★★★★
()
Ответ на: комментарий от d_a

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

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

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

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

d_a ★★★★★
()

привелегий

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

one_more_hokum ★★★
()
Ответ на: комментарий от d_a

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

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

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

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

Aceler ★★★★★
()
Последнее исправление: Aceler (всего исправлений: 1)
Ответ на: комментарий от Aceler

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

Конечно.

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

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

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

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

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 2)
Ответ на: комментарий от DRVTiny

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

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

one_more_hokum ★★★
()
Ответ на: комментарий от d_a

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

Нет:

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

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Нет

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

d_a ★★★★★
()
Последнее исправление: d_a (всего исправлений: 1)

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

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

kto_tama ★★★★★
()
Ответ на: комментарий от pacify

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

MrClon ★★★★★
() автор топика
Ответ на: комментарий от Aceler

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

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

MrClon ★★★★★
() автор топика
Ответ на: комментарий от vel

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

MrClon ★★★★★
() автор топика
Ответ на: комментарий от MrClon

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

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

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

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

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

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

Aceler ★★★★★
()
Ответ на: комментарий от MrClon

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

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

Aceler ★★★★★
()
Ответ на: комментарий от imul

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

Aceler ★★★★★
()

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

# 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

znenyegvkby
()

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

Deleted
()

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

anonymous_sama ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

MrClon ★★★★★
() автор топика
Ответ на: комментарий от Rost

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

MrClon ★★★★★
() автор топика
Ответ на: комментарий от d_a

MAC (SELinux) не нужен

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

aidaho ★★★★★
()
Ответ на: комментарий от Aceler

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

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

ls-h ★★★★★
()
Ответ на: комментарий от robotron5

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

MrClon ★★★★★
() автор топика

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

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

anonymous
()
Ответ на: комментарий от snaf

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

anonymous
()
29 декабря 2016 г.
Ответ на: комментарий от MrClon

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

nobody?

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.