LINUX.ORG.RU

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


0

0

Этот документ демонстрирует ошибки ядра Линукса в реализации обработки связанных списков, используемых для регистрации бинарных форматов. Эта проблема касается всех веток ядра (2.0/2.2/2.4/2.6) и позволяет загружать специальные модули для заражения в область ядра, что позволяет злонамеренным пользователям запускать на системе rootkit'ы. Пример атаки, её описание и детали реализации читайте по ссылке (PDF).

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

Ответ на: комментарий от GladAlex

да ничего не означает. В статье описан еще один способ поставить руткит в обход grsecurity/selinux на всех архитектурах. Там же патч, спасающий от этого способа.

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

Не пойму, чего такого-то?

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

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

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

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

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

Да нет, надо именно загрузить ядерный модуль и зарегистрировать новый бинарный формат. Короче, ничего особенного.

ero-sennin ★★
()
Ответ на: комментарий от anonymous_incognito

Цитата из pdf'ки:

- The technique may be used with root privileged only.

- The kernel patches like GRSEC, and the kernel level security implementations like SELINUX, do not contemplate the insertion of non valid binary formats nor the functions references in kernel­space for this list of binary formats.

- The technique was successfull on 2.4.x y 2.6.x kernels, the test cases were done using the following kernel versions: 2.4.33 y 2.6.17.11

только. от. рута. новость ниачем.

anonymous
()

Чего панику среди честных людей разводим? Нету рута - нету бага. Есть рут - так и так можно делать что угодно.

Это значит только то, что 1 мелким багом скоро будет меньше.

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

> The technique may be used with root privileged only.

Вот, не заметил, когда по диагонали читал. То есть получается актуальна эта штука только при наличии мандатных систем безопасности, а без них просто альтернативный insmod'у способ :)

anonymous_incognito ★★★★★
()

Я чёт не понял, эт замороченная версия команды
root@localhost # cd rootkit && make && make install ?

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

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

ero-sennin ★★
()
Ответ на: комментарий от hzk

взять эксплоит, повыщающий права пользователя до рута, и вперед, дальше дело техники и работы эксплоита.

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

> Не понял пока. Но, даже у M$ ошибок в загрузчике PE я не помню.

Начнем с того что загрузчик PE кроме PE грузить ничо не умеет. А граблей в нем столько, что весь ихний линкер воркэраундами утыкан. Можно нараз создать PE который грузится в 2k и не грузится XP, равно как и наоборот, причем оба бинаря будут строго удовлетворять мелкомягкой спецификации на PE формат. Разработчики крипторов и протекторов горючими слезами плакают от этого...

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

рут - это самая страшная фича, но никак не баг :)

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

>>взять эксплоит, повыщающий права пользователя до рута, и вперед, дальше дело техники и работы эксплоита.
Если поднять права до рута - остальные эксплоиты нах не нужны уже ;-)

sabonez ★☆☆☆
()

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

e
()
Ответ на: комментарий от ero-sennin

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

pdf что-то больно долго качается so по старой традиции буду обсуждать новость не читая ее.

anyway, я за 10 минут напишу модуль, который при каждом например open(2) будет выполнять произвольный код в контексте ядра. ну и то с того? его же загрузить нужно, модуль. а если я могу загрузить модуль то всей системе автоматом наступает полный писец. tested :)

// wbr

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

>я за 10 минут напишу модуль, который при каждом например open(2) будет выполнять произвольный код в контексте ядра для ядра 2.6 уже не выйдет а тут вроде бы для фсех ядер з.ы. Service Temporarily Unavailable :(

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

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

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

> для ядра 2.6 уже не выйдет а тут вроде бы для фсех ядер з.ы. Service Temporarily Unavailable :(

выйдет выйдет, tested. все прекрасно работает на 2.4/2.6 с полным перехватом VFS и никакой SELinux не спасает ;) ну а уж просто прибить систему из вредности - это как два пальца.

// wbr

klalafuda ★☆☆
()

binfmt ??? А не боян ли это ??? и много ли народу пользуется iBCS ???

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

> выйдет выйдет, tested. все прекрасно работает на 2.4/2.6 с полным перехватом VFS и никакой SELinux не спасает ;)

А код слабо запостить? :P

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

>А код слабо запостить? :P

Зачем ?? Пишеш ЛЮБОЙ драйвер ... и при обращении к нему делаешь что хочешь ... вот и вся "дыра"

robot12 ★★★★★
()
Ответ на: комментарий от ero-sennin

> А код слабо запостить? :P

конечно слабо бо закрыт он :) но сама по себе идея в сущьности тривиальна - лезем ко всем объектам VFS, до которых можем дотянуться и подменяем на себя вектора операций сохраняя оригинальный. при вызове уже своей операции делаем нечто, что подскажет буйная фантазия, после чего вызываем оригинальную операцию и возвращаем ее результат если есть. вот в сущьности и весь код. и это прекрасно работает на всеми любимом RHEL4 с его штатным ядром 2.6.9 и включенным SELinux. на SUSE10 впрочем то-же работает, а большего и не надо.

ps: да в сущьности почему нет? от подобного варварства со стороны модуля IMHO очень трудно защититься [если вообще возможно].

// wbr

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

anonymous_incognito в следующий раз , такую "новость" подтверждать будешь ... сначала убедись ... что это новсть и что она не боян.

>Но, даже у M$ ошибок в загрузчике PE я не помню.

Уважаемый, скажика, а оно умеет что нитьт кроме PE и NE грузть ? OS/2 подсистема в NT не может даже LX погрузить, и никакой возможности расширить количество поддерживаемых форматов просто нет. А в драйвер какашку прописать можно и для M$ вантуза, многие ли разработчики подписывают драйверы ???

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

> конечно слабо бо закрыт он

Вы там что, руткиты делаете на коммерческой основе? :D А как же GPL?

> но сама по себе идея в сущьности тривиальна...

Всё-таки, это гораздо сложнее сделать, чем просто добавить лишний элемент в начало списка бинарных форматов, как описано в статье.

ero-sennin ★★
()
Ответ на: комментарий от klalafuda

>подменяем на себя вектора операций

Каким образом? ссылку можно? т.е я так понимаю что речь не о подмене системного вызова. Покажи где учить матчасть :)

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

> Вы там что, руткиты делаете на коммерческой основе?

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

> :D А как же GPL?

кому она упала эта жпл? :)

> Всё-таки, это гораздо сложнее сделать, чем просто добавить лишний элемент в начало списка бинарных форматов, как описано в статье.

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

// wbr

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

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

дык самым что ни на есть прямым. например, у inode есть указатель i_op на ее вектор операций inode_operations. достаточно создать свой вектор, заполнить его указателями на собственные операции и подменить текущий i_op на свой, сохранив где-то старый. после все операции с inode будут протекать уже через наш код. аналогично с другими объектами VFS типа super_block, file etc.

> ссылку можно? т.е я так понимаю что речь не о подмене системного вызова. Покажи где учить матчасть :)

ссылку нельзя бо я ее никогда не видел, эту ссылку :) может и есть где-то в сети нечто на эту тему, я не знаю.

// wbr

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

> Каким образом? ссылку можно? т.е я так понимаю что речь не о подмене системного вызова.

btw подменить системный вызов на порядок сложнее бо таблица системных вызовов жестко прописана статиком где-то в недрах ядра и из модуля так просто недоступна :( впрочем, в принципе есть грязные хаки на эту тему. это вам не BSD, где без особых проблем можно зарегистрировать собственный системный вызов или же перехватить существующий. вообще за идею с EXPORT_SYMBOL() я бы расстреливал :-/

// wbr

klalafuda ★☆☆
()

LOL...

Еще бы написали что пропатченое ядро патчем ххх.patch будет уязвимо и чтоб использовать эту уязвимочть надо залезть (желательно физически) с рутовыми правами на машину, пропатчить ядро, перекомпилировать, перезагрузится с уже нового пропатченого ядра и потом запускать програмы с несанкционированым виполнением кода контекста ядра... Ууу, какая сверхмегакритическая уязвимость, все линукс-серверы и воркстейшны завтра перестануть работать, кулхацкеры пропатчят и перекомпилят ваши ядра... Бойтесь... LOL... ))))))))

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

> кому она упала эта жпл? :)

Мсье вонючий проприетарщик и нарушитель действующего законодательства?

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

абсолютно ничего сложного, 15 строчек кода. код не дам, ибо против тупых скрипткиддесов, которые не хотят читать хотябы phrack. там есть баянистая статья как найти из модуля адрес таблицы системных вызовов. Он работает и будет работать всегда, хотя и в явную этот адрес модули не экспортируется. У меня отлично пашет вплодь до 2.6.18. а от lkm руткитов защитит цифровая подпись модулей(аля мс виста) и ее проверка перед загрузкой модуля. проект: http://disec.sourceforge.net/

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

>подменить системный вызов на порядок сложнее

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

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

> абсолютно ничего сложного, 15 строчек кода. код не дам, ибо против тупых скрипткиддесов, которые не хотят читать хотябы phrack. там есть баянистая статья как найти из модуля адрес таблицы системных вызовов. Он работает и будет работать всегда, хотя и в явную этот адрес модули не экспортируется. У меня отлично пашет вплодь до 2.6.18.

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

// wbr

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

> предыдущий пост - от другого анонимуса а за идею с EXPORT_SYMBOL()я бы не расстреливал всё таки. Ну кто виноват что руткиты пользуются теми же методами :)))

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

// wbr

klalafuda ★☆☆
()

у мееняы на всю систему -CAP_SYS_MODULE, так что даже рут не сможет вставить своего модуля.
вива-ля rsbac! :)

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

В SELinux существуют механизмы ограничения прав в том числе и рута. Существуют механизмы запрещения изменения этих прав, и изменить их можно только физически перегрузив сервер. Именно это и позволяет обходить данная уязвимость.

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

> После echo "off" > /proc/modules ни на ASPLinux ServerIV, ни на v11 уже ничего не сделаешь.

ну кто спорит. тогда уж лучше их вообще запретить и дело с концом :)

// wbr

klalafuda ★☆☆
()

Уязвимость бинарного формата ядра Линукса - вымысел. За всем стоит Microsoft.

Надо было г-жу Шнайдер приглашать в kernel team, тут от неё больше пользы было бы :)

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

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

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

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