Уязвимость в ядрах 2.4.* и 2.6.*

ну щас начнется...

Что-то в последнее время ядро как пирожки выпускают :-/ Наляпают побыстрому, выпустят, а потом спохватываются - "Ой, дырочки остались". Может имеет смысл выпускать новые ядра менее быстро, но более качественные?

/me пошел пробовать

Cathedral and the Bazaar

И какие катастрофические последствия могут быть ?

init убить реально?

Ты, видимо, из комитета стратегического планирования развития ядра?

Новость запостил саныч. Единственное катастрофическое последствие этой новости - катастрофический флейм :)

А ты инит каким юзером запускаешь? :-))

Linux R.I.P.

sabonez@sabonez:~> ps aux | grep init

root 1 0.0 0.0 744 188 ? Ss Aug21 0:01 init [5]

>Linux R.I.P.

http://www.tux.org/pub/people/kent-robotti/looplinux/RIP/
                                               ^^^^^^^^^^^ давно уже 

<flame>А в Солярке кто-то пробовал? </flame>

Новость не читаем? Написано же: *дочернему* процессу. инит - это родительский процесс.

патч вышел 2 дня назад: это не новость, я баян :)

Дочернему? И что? Я тебя породил, я тебя и убью...

>>Новость не читаем?

ТруЪ ЛОР-овцы они не тока по сцылкам не ходят ;-)))

>давно уже

The requested URL /pub/people/kent-robotti/looplinux/RIP/ was not found on this server.

:(

>я баян :)

Дожили...

Фигня а не уязвимость, не запускайте "левых" программ Но в целом неприятно что не проверили всех последствий введения с 2.1.57. fork стирает а почему execve не стирает не понятно.

хотя может так и было задумано?

> я баян

"йа креведко" отдыхает.

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

> init убить реально?

назовите для init родительский процесс с более низкими привилегиями, ну или вообще родительский процесс (hint: pstree)

И правда.. Саныч, а чего ты о более важном, патче, не упомянул? Как никак повод для 2.6.22.4 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22.4

не заметил опечатки :)

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

Если бы можно было использовать, новость бы начиналась со слова "Нииба^WКритическая" :)

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

во, толькочто придумал пример: есть комп под линухом для обученя в школе/уневере с юзверем student/guest/..., и заходить на него по ssh можно только под этим юзверем. т.е. чтоб получить админу соответствующие права, ему нужно зайти под непривилегированным пользователем и через su получить рута. но тогда любой ученик/студент сможет набрать типа killall bash и кильнуть шелл, с которого зашел админ (юиды одинаковые, значит можно). а он, в свою очередь, кильнет все дочерние процессы, в т.ч. и su, который уже под рутом (вроде так... если нет, тогда отбой ;) )

я еще только новичёк в линуксе но я очень хочу взламать какой-нибудь сервер дайте мне эксплоит пожалуйста!!1

>и заходить на него по ssh можно только под этим юзверем. т.е. чтоб получить админу соответствующие права, ему нужно зайти под непривилегированным пользователем и через su получить рута. но тогда любой ученик/студент сможет набрать типа killall bash и кильнуть шелл, с которого зашел админ (юиды одинаковые, значит можно)

не получиться, SIGTERM для этого (судя из уязвимости) нужно посылать из родительского процесса (т.е.из sshd), но никак не из соседнего баша.

>И какие катастрофические последствия могут быть ?

Управление suid програмами посредством сигналов?

Вот за что уважаю OpenWall. August 14, 2007 Linux 2.4.35-ow2 is out. This revision adds a fix for the "parent process death signal" vulnerability in the Linux kernel.

А по поводу сроков новости:

[ DISCLOSURE TIMELINE ]

27th July 2007 Vendor notification

14th August 2007 Public disclosure

22th August 2007 Today

http://www.tux.org/pub/people/kent-robotti/looplinux/rip/

> Управление

> ?

А можно без общих слов и вопросительных знаков? Какой конкретно суицидной программой в обычном дистре можно "управлять" посредством сигналов со сколько-нибудь "уязвимыми" последствиями?

> init убить реально?

Конечно реально: сначала убиваешь ядро как родителя, потом посылаешь сигнал смерти иниту.

> не получиться, SIGTERM для этого (судя из уязвимости)
> нужно посылать из родительского процесса (т.е.из sshd),
> но никак не из соседнего баша.

вы меня немножко не так поняли.
я не имел в виду НЕПОСРЕДСТВЕННОЕ убийство рутового баша.

только что проверил на живой машине. работает. по шагам:

1. запустил konsole, в нем два bash'а.
   в первом через su получаю баш с рутом.
   во втором смотрю дерево (pstree -pu):

... ...
... |-konsole(4860)-+-bash(4866)---bash(4900,root)
... |               `-bash(4872)---pstree(4907)
... ...


2. во втором делаю kill -KILL 4866

... ...
... |-konsole(4860)---bash(4872)---pstree(4911)
... ...


3. проверяю бывший рутовый баш:

kill 4900
bash: kill: (4900) - Нет такого процесса


вотЪ...

> А можно без общих слов и вопросительных знаков? Какой конкретно суицидной программой в обычном дистре можно "управлять" посредством сигналов со сколько-нибудь "уязвимыми" последствиями?

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

ps: нет, с ходу пример не придумаю.

// wbr

а что значит "с более высокими привилегиями", в классическом unix (безо всяких там selinux) есть только два вида пользователей: uid 0 и все остальные.

Блин, чет не могу найти ядро в списке процессов (

ок, сори =)

>Блин, чет не могу найти ядро в списке процессов (

поищи получше, (hint: убей все процессы events, ksoftirqd, kswapd kblockd, kthread и прочие похожие)

ps видишь суслика?

> ps: нет, с ходу пример не придумаю.

Вот и я тоже. :) Хотя теоретически, наверное да. :)

> во, толькочто придумал пример: есть комп под линухом для обученя в школе/уневере с юзверем student/guest/..., и заходить на него по ssh можно только под этим юзверем. т.е. чтоб получить админу соответствующие права, ему нужно зайти под непривилегированным пользователем и через su получить рута. но тогда любой ученик/студент сможет набрать типа killall bash и кильнуть шелл, с которого зашел админ (юиды одинаковые, значит можно). а он, в свою очередь, кильнет все дочерние процессы, в т.ч. и su, который уже под рутом (вроде так... если нет, тогда отбой ;) )

ну вообще то в указанном поведении нет никаких багов бо студент может послать -KILL на родительский sshd, который - в системе с одной учетной записью - будет под тем же uid что и сам студент -> все законно.

мораль: делайте хотя бы два логина - пользовательский и административный. последний кстати совершенно не обязательно делать с uid/gid=0 а первый - с правами на su.

// wbr

> ну вообще то в указанном поведении нет никаких багов бо студент может послать -KILL на родительский sshd, который - в системе с одной учетной записью - будет под тем же uid что и сам студент -> все законно.

эта... а причем тут sshd под студентом? с таким же успехом можно было сказать "...и если студенты знают пароль рута, ...".

> мораль: делайте хотя бы два логина - пользовательский и административный. последний кстати совершенно не обязательно делать с uid/gid=0 а первый - с правами на su.

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

и вот еще пример ситуации: студенты заявили, что у них чего-то не работает, админ логинится под студентом (для чистоты эксперимента), проверяет, быстро набирает su/пароль и делает быстренько apt-get upgrade, а студенты в самый интересный момент киляют его баш н/п юзера, нарушив при этом целостность системы.

Все сервисы стартую от root`а по схеме вроде: su -c "сервес" пользвтль. Если кто-то сможет стать root`ом то ему незачем будет этот сплойт.

А так канечна крута, наделать башей и один из другого килять :)

Почему теоретически? Какой еще механизм можешь предложить для управления демонами кроме сигналов?

А почему Вы таки отвечаете вопросом на вопрос?

нет, по ссылкам я конечно не ходил, но безусловно осуждаю. что-то мне представляется что это была скорее фича, нежели чем бага. ситуация: взбредает кому-то диск записать. запускает от k3b. k3b рождает писалку с euid root, дабы могуществом своим могла она основы компьютера потрясти и заставить своей воле повиноваться реалтаймово. процесс идет, злобный и жестокий красный лазер перефигачивает нежную органику внутри диска, и тут человек понимает что диск который он пишет, суть КГ/АМ. он командует k3b "отменить". и.. что теперь прикажете k3b делать?

ну.... пайпы к примеру.

Не, это однозначно бага. Что касается суидной писалки, то k3b её родит в псевдотерминале, а через него пошлёт ctrl-c, что вызовет отправку драйвером псевдотерминала писалке SIGINT'а. Так что ты за k3b не беспокойся. :)

Но и бага такая, которая новости не заслуживает.