Опасная уязвимость OpenSSH в RHEL и Fedora

РЕШЕТО!!! принято кричать в первых постах.

А мне всегда казалось, что такие новости в разделе о BSD

>Наличие доступа к консоли без chroot, для того, чтобы сделать hardlink на suid-файл внутри chroot-окружения.

Возможно я идиот, но до меня не доходит, зачем имея доступ к консоли без чрут, делать этот хардлинк на чрутовое окружение, а не запустить сразу suid бинарник, обьясните кто-нидь.

Ентерпрайз!

>Возможно я идиот, но до меня не доходит, зачем имея доступ к консоли без чрут, делать этот хардлинк на чрутовое окружение, а не запустить сразу suid бинарник, обьясните кто-нидь.

Патамушта этот suid бинарник будет юзать конфиги и либы, принадлежащие руту, в которые ты закладок напихать не можешь.

> а не запустить сразу suid бинарник, обьясните кто-нидь

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

> Наличие доступа к консоли без chroot, для того, чтобы сделать hardlink на suid-файл внутри chroot-окружения.

Немного не так, это искажает смысл.

Правильнее было бы: пользователь должен иметь доступ к окружению за пределами chroot (например, с консоли, либо уже иметь шелл-доступ в систему и к chroot-директории до того, как он был перемещен в chroot)

РЕЩЕТО!! Как ЭТО могло попасть в RHEL-не понятно.

Ничего не решето. Произвольный код можно выполнить только внутри чрута, то есть секонд чрут - единственное, что представляет угрозу безопаности - невозможен. Или я не прав?

Вот те раз :(((

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

Не прав. Будучи рутом, можно вылезти из чрута. Что-то типа

mknod c /dev/sda 8 0
mount /dev/sda /mnt
chroot /mnt

Классический вариант атаки на чрут выглядит так:

mkdir ~/etc/
mkdir ~/bin/
vi ~/etc/passwd
ln /bin/su ~/bin/su
chroot ~
su -
???
profit

Поэтому, собственно, обычному юзеру запрещена операция chroot(2).

В данном случае, при некотором попустительстве администратора системы, ссшд покорно сделает чрут в контролируемый пользователем каталог -- и поможет в реализации данной атаки.

>Произвольный код можно выполнить только внутри чрута...

Угу, копируем в чрут /bin/sh из хост-системы и chmod +s его. После чего бежим к локальной консоли вне чрута (которая по условию есть) и запускаем.

>...потенциально позволяющая удаленному пользователю...

Согласно условиям задачи у злоумышленника должна быть консоль хоть из-под кого-то. Каким образом это тогда remote exploit? Тут повышение привелегий через жопу. Или я что-то не допонял?

а вы всё Дебиан Дебиан...

>Согласно условиям задачи у злоумышленника должна быть консоль хоть из-под кого-то.

Достаточно ssh с chroot + ssh без chroot. И все будет работать удаленно!

> Угу, копируем в чрут /bin/sh из хост-системы и chmod +s его.

это не поможет
юзер сменится при копировании и вы получите suid на самого себя
нужен именно линк
а это на серванте крайне маловероятно (хомяк и корень редко в одном раздела)

> Согласно условиям задачи у злоумышленника должна быть консоль хоть из-под кого-то.

и права на запись в будущий чрут. так что не "из-под кого-то"

> Каким образом это тогда remote exploit? Тут повышение привелегий через жопу. Или я что-то не допонял?

никакой это не remote exploit

>это не поможет
>юзер сменится при копировании и вы получите suid на самого себя

Конечно, спасибо за уточнение. Получается на одну команду внутри чрута больше:
chown root /my/sh
chmod +s /my/sh

>хомяк и корень редко в одном разделе

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

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

> chown root /my/sh

это тоже не сработает. по определению ;)
только ln на нечто, что в /sbin и /usr/sbin
и готовить свою либу для помещения в чрут

Мне кажется, мы с Вами друг друга несколько не поняли.

Я отвечал своим "chmod +s" на коммент, где говорилось про невозможность/сложность выхода из чрута. А при данных начальных условиях (уже есть локальный доступ) в этом просто нет необходимости.

Собственно _использование_ уязвимости (т.е. эксплойт) таким способом, разумеется, невозможно.

> Мне кажется, мы с Вами друг друга несколько не поняли.

точно. прошу прощения

и кто-то ещё издевался над Debian?

>выполнить произвольный код с привилегиями root, но без возможности выйти за пределы chroot-окружения.

рут из чрута выходит в два чиха

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

>и кто-то ещё издевался над Debian?

Угумс. Издевались, издеваемся, и будем издеваться :)

Чтобы заюзать эту дыру, нужен как минимум о-о-очень тупой админ и редкое стечени обстоятельств.
В отличие от «случайных» SSH-ключей демьяна http://xkcd.com/221/ :)

>покажите где такое может быть.

написано же в новости: RHEL и Fedora

сомневаюсь что можно 2 раза монтировать блочный девайс.

в списке уязвимых указаны только фёдора и ред хат. а центос не подверен этой уязвимости?

OpenSSH в RHEL

Когда-то эта связка мне в $500 влетела... Когда за квартиру в Москве по $200 платили. Вызывающее с тех пор душевный трепет слово Slapper :)

по традиции: кхм-кхм! РЕШЕТО!!!

>в списке уязвимых указаны только фёдора и ред хат. а центос не подверен этой уязвимости?

Ну что за народ...
Написано же: дыра появилась в RHEL 5.4. Центос этой версии кто-нибудь видел?

> Центос этой версии кто-нибудь видел?

Естественно. В обновлениях лежит уже месяц, если не больше. Или ты считаешь, что если iso'шек нет, значит и дистрибутива нет?

Естественно. В обновлениях лежит уже месяц, если не больше. Или ты считаешь, что если iso'шек нет, значит и дистрибутива нет?

Иногда лучше жевать, чем говорить :)

Свежеобновленный центос:

[root@xenix ~]# lsb_release -ir
Distributor ID: CentOS
Release:        5.3

Специально для латентных вендузоидов рекомендую сравнить версии ключевых пакетов (glibc, kernel, gcc).

Таки да, специально для домохозяек они не меняют циферку, пока не выложат iso'шки. И таки да, домохозяйки ведутся, судя по всему.

>Таки да, специально для домохозяек они не меняют циферку, пока не выложат iso'шки. И таки да, домохозяйки ведутся, судя по всему.

У-тю-тю!
Ты с размаху пернул в лужу, а теперь еще и неуклюже пытаешься отмазаться, называя собеседника латентным вендузоидом и домохозяйкой.
Что ж, твои способности швыряться какашками прекрасны, но вовсе не компенсируют незнания тобой центоса :D

> в списке уязвимых указаны только фёдора и ред хат. а центос не

> подверен этой уязвимости?

Центос конечно же подвержен. Там та же самая уязвимая версия openssh-4.3p2-36.el5. Ждите обновления, вот вот должны выложить.

> А мне всегда казалось, что такие новости в разделе о BSD

OpenSSH разрабатывается командой OpenBSD. Вот как опасно портировать в Linux BSD'шные программы. ;-)

>Вот как опасно портировать в Linux BSD'шные программы. ;-)

Если руки кривые, опасно портировать вообще все отовсюду куда угодно :)

>Обновления доступны уже две недели. Не забываем обновляться каждое утро!

Только что обновился, но по прежнему openssh-server-5.2p1-2.fc11.x86_64, в чейнджлоге ни слова о фиксе. У меня неправильное зеркало обновлений или что?

>>покажите где такое может быть.

>написано же в новости: RHEL и Fedora

а теперь перечитай мой пост еще раз, особенно то что написано в скобках и пойми что тут всего лишь недобекпортили ``защиту от дурака''

>Только что обновился, но по прежнему openssh-server-5.2p1-2.fc11.x86_64, в чейнджлоге ни слова о фиксе. У меня неправильное зеркало обновлений или что?

На самом деле подвержены вовсе не все версии Федоры. На момент открытия уязвимости дыра была только в тестовой версии. Просто я не стал это уточнять, чтобы получить более зрелищную панику :)
Так что тссс!

P.S. Если серьезно, лучше перебдеть, чем недобдеть.

В отличии от Дебиана, тут подразумеваются платные услуги вендора, и отношение к их качеству будет построже. На мой взгляд это достаточно серьёзно, на уровне типичных уязвимостей от M$. Т.е. боевой сервер надо по-прежнему делать с умом и перестраховываться, поддержка поддержкой, но вс же сисадмин должен быть очень и очень хардкорный.

>РЕШЕТО!!!
+1024

Действительно решето.

рут через ssh? это уже не решето, это уже через рот асфальт видно.

>рут через ssh? это уже не решето, это уже через рот асфальт видно.

4.2

"Рут через ссш при наличии локального доступа и кривой конфигурации" и "рут через ссш" это две большие разницы.

Все это типичное велосипедостроение и затыкание дырок.

Ах в ядре нет чрута от не-рута? Ну так сделаем свой велосипед!!!!11111

Тогда как правильно было бы:

А. Расширить сис.вызвов чрут на не-рута, при этом, для защиты, запретить каждому не-рут-чрутнотому процессу (и его потомкам) исполнять суидные бинарники и делать повторный чрут (тема обсуждалась в development)

Б. ССШ делает уже не-рутовый чрут

>> chown root /my/sh

> это тоже не сработает. по определению ;)

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

> Конечно, спасибо за уточнение. Получается на одну команду внутри чрута больше:
> chown root /my/sh
> chmod +s /my/sh

установка флага суид автоматом превращает тебя в владельца. иначе это работало бы и для обычного пользователя.

> Но, чтобы chroot был полезен, там должен быть минимальный набор команд, в том числе наверняка какой-нибудь шелл и даже, возможно, суидные программы.
нет. есть ведь еще scp. и еще, какие-такие суидные программы могут потребоваться пользователю, которого ты сознательно ограничиваешь и сажаешь в чрут? ты что, самоубийца? если там _уже_ есть суид-программы, тебе даже не надо ничего линковать => не нужен доступ без чрута. просто библиотечку дописываешь, и готов