Уязвимость бинарного формата ядра Линукса

>> Каким образом?

>дык самым что ни на есть прямым. например, у inode есть указатель i_op на ее вектор операций inode_operations. достаточно создать свой вектор, заполнить его указателями на собственные операции и подменить текущий i_op на свой,

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

P.S. Это из-за такой задачи ты ругал линуксовую VFS?

> А что делать с инодами, которые оказались в памяти до загрузки твоего модуля? Искать и менять?

хороший вопрос, он меня то-же долго волновал. ограничения:

0. должно работать как модуль в пределах заданных дистрибутивов с их родными ядрами. собственно, 99% что RHEL + возможно SLES. варианты с модификацией и пересборкой ядра не рассматриваются. левые дистрибутивы и ядра не рассматриваются. это к тому, что неработоспособность в дистрибутиве ABC отлично от никого не волнует.

по-хорошему - да, искать и менять. менять не проблема, но вопрос - как искать бо таблица inode статиком объявлена. варианта я вижу как минимум два:

1. грузить модуль как можно раньше [это в любом случае полезно]. собственно, если грузить модуль в момент, когда корень еще r/o i.e. до перемонтиоования в r/w то на эти иноды в принципе пофигу. да и немного их там в принципе при загрузке.. если допустим актуально перехватывать события от некого /var/spool/mail который на момент загрузки еще не смонтирован, то все вообще шоколадно. в общем, это зависит от. можно еще для проформы invalidate_inodes() позвать, что впрочем не гарантирует, что снесутся все. точнее, все точно не снесутся но все легче.

2. с какого-то момента у суперблока 2.6 появилось поле AFAIR s_inodes в котором лежит список всех инод, принадлежащих этому суперблоку. далее уже пройтись по ним и подменить вектора дело техники. но это SMP unsafe бо локи списка суперблоков не экспортируются* :( впрочем, зависит от конкретной ситуации и решаемо. еще проблема в том, что не на всех 2.6 это есть и появилось как минимум после 2.6.9 (RHEL4) что есть криво в силу п.0.

> Что-то я не верю, что вся эта паутина может работать надежно.

работает достаточно надежно с определенными ограничениями :) а что делать..

> P.S. Это из-за такой задачи ты ругал линуксовую VFS?

в том числе.. впрочем, ко всему можно привыкнуть.

ps: кстати, dazuko рулит. вполне вменяемая штуковина с рядом интересных идей, respect.

*) &^%^%$&$# убил бы за EXPORT_SYMBOL() толку ноль а гемору вагон с тележкой :-E хоть свой insmod пиши если вообще поможет..

// wbr

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

Ну и будет у тебя рутовый пароль и физический доступ и чо ты сможешь если там будет стоять selinux и роль у рута будет user_r :)

> Ну и будет у тебя рутовый пароль и физический доступ и чо ты сможешь если там будет стоять selinux и роль у рута будет user_r :)

Берешь кувалду и ...
Вообщем-то и рутовый пароль не нужен :)

> прекрасно работает на всеми любимом RHEL4 с его штатным ядром 2.6.9 и включенным SELinux. на SUSE10 впрочем то-же работает

У меня хоть и сусе 10.1 но я живу под chroot. Там где должны быть модули ядра ветер гуляет, да и insmod и прочего нет. Ну и как это оно работает.

> убил бы за EXPORT_SYMBOL() толку ноль

Экспортирует символы, за что убивать-то?

> гемору вагон с тележкой :-E

Какой такой гемор?

> хоть свой insmod пиши

insmod - штука совершенно тривиальная ;) Так что не поможет

> o_O - а пароль зачем? Акуратно кусачками отрезаем провод...

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

> Ну и будет у тебя рутовый пароль и физический доступ и чо ты сможешь если там будет стоять selinux и роль у рута будет user_r :)

Грузанусь со сменного носителя и резво превращусь в god_fuck_em_all ;)

>> убил бы за EXPORT_SYMBOL() толку ноль
> Экспортирует символы, за что убивать-то?
>> гемору вагон с тележкой :-E
> Какой такой гемор?

такой, что если в ядре объект даже и объявлен как глобальный, без соотв. EXPORT_SYMBOL() до него из модуля хрен доберешься. а иногда ну очень надо. характерная вещь - спинлоки на внутренние объекты. причем что до самих объектов добраться можно, а вот корректно заблокировать - хрен. ну и нафига такие прятки устраивать и кому это вообще нужно? типа "stable public kernel API"? если бы так и это бы еще работало, но ведь сломать API между минорными версиями умудряются и с EXPORT_SYMBOL() so совершенно побоку, лишь геморой :-/

> insmod - штука совершенно тривиальная ;) Так что не поможет

ugu

// wbr

> ну и нафига такие прятки устраивать и кому это вообще нужно?

Дык у виндовса - рок-стейбл АПИ, а ломают на раз. Вот и сделали сию чехарду дальновидные ребятки из кернел-тима, для "облегчения" жизни всяким злоумышленникам ;)

>> ну и нафига такие прятки устраивать и кому это вообще нужно?
> Дык у виндовса - рок-стейбл АПИ, а ломают на раз. Вот и сделали сию чехарду дальновидные ребятки из кернел-тима, для "облегчения" жизни всяким злоумышленникам ;)

каким здесь боком MS Windows? мы вообще-то про Linux говорим.

// wbr