ты так говоришь, будто это вещи одного множества.

это вещи одного множества :)

3.2.29-smp slackware

не работает.

Однострочник на перле и ядро сабжа, в таком случае, тоже.

MINIX 3 разработана с целью обеспечить высокую надежность, гибкость и безопасность. Части, которые работают в пользовательском режиме, разделены на маленькие модули и хорошо изолированы друг от друга. Например, каждый драйвер устройства выполняется как отдельный процесс пользовательского режима, и ошибка в драйвере не может полностью остановить операционную систему. В MINIX 3, когда драйвер терпит крах, он автоматически перезапускается, не требуя никакого пользовательского вмешательства, не требует перезагрузки, и не затрагивает выполняющиеся программы. Эти особенности, микроядро и другие аспекты очень повышают надежность системы.

Подвержены ли микроядра подобному типу «local root» уязвимостей?
В качестве примера ядро ОС Minix 3.

Марк Балмер душка :)

имеется ввиду - меньшему проценту макоюзеров эти бандлы интересны

Linux AquaBlast 3.6.11-gentoo #5 SMP Tue Jan 22 13:47:16 MSK 2013 x86_64 AMD Phenom(tm) II X4 B35 Processor AuthenticAMD GNU/Linux

$ ./woopi 00 (а также 01,02)

Current uid is 1000 Sucking up the whole VM space Creating 1G file...100.00% 70340826890240b 68692213760.000000Kb 67082240.000000Mb 65510.000000Gb Will dereference sock_diag_handlers[57] Shit, or what?

Подвержены ли микроядра подобному типу «local root» уязвимостей?

Да, конечно.

В качестве примера ядро ОС Minix 3.

У Minix главная проблема — по своим возможностям это ОС уровня MS DOS. Она поддерживает очень мало оборудования, и из-за микроядерности драйверы для нее писать далеко не так легко, как для Linux. Под minix очень мало программ, хотя какая-то старая версия firefox-а под неё была.

А все лозунги про безопасности и перезапускаемость упавших драйверов — это всего лишь лозунги. Микроядерность не помешает глючному драйверу файловой системы испортить файлы на диске. Микроядерность не помешает используя уязвимость в драйвере сетевой карты выполнить код в его контексте. И уж тем более микроядерность никак не спасет от обычных багов в юзерспейсе, типа sshd или apache.

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

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

Linux AquaBlast 3.6.11-gentoo #5 SMP Tue Jan 22 13:47:16 MSK 2013 x86_64 AMD Phenom(tm) II X4 B35 Processor AuthenticAMD GNU/Linux

Этот эксплоит заточен под 32-битные ядра. Под конкретные три ядра. Тут выше была ссылка на универсальный сплоит для федоры, но тоже 32-битной. Хотите использовать его в 64-битном ядре — подберите другие адреса и исправьте эксплоит.

Хотите использовать его в 64-битном ядре — подберите другие адреса и исправьте эксплоит.

Кстати, попробуйте вариант sd: http://pastebin.com/a9BrSGFY Он вообще-то под арч писался, но 64-битный.

Давненько я не видел новостей от birdie, может слоупочу?

До следующей local root не ждите ;-)

2 anonymous

Спасибо за подробное разъяснение.

А все лозунги про безопасности и перезапускаемость упавших драйверов — это всего лишь лозунги. Микроядерность не помешает глючному драйверу файловой системы испортить файлы на диске.

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

Буфер не копируется каждый раз туда-сюда, он так и ходит в виде указателя по всему ядру. Провернуть подобное в «безопасной микроядерной архитектуре» почти невозможно.

Почему? Расшарить кусок памяти и перекидывать между процессами такой же указатель, не?

Аа. Я что-то вообще заблудился, какими дистрами ты в основном пользуешься =)

В opensuse 12.2 сейчас стоит 3.4.28-2.20-desktop

Но я буду наивно полагать, что мне плевать на данную уязвимость.

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

Этот эксплоит заточен под 32-битные ядра. Под конкретные три ядра. Тут выше была ссылка на универсальный сплоит для федоры, но тоже 32-битной. Хотите использовать его в 64-битном ядре — подберите другие адреса и исправьте эксплоит.

Честно? Не хочу :) Мне достаточно того, что у меня эта дрянь не работает. Появится под 64 бита — потестим.

Но всё же она помешает глючному драйверу вебки сделать то же самое.

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

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

Собственно, из того же процесса код и дергается. :)

Почему? Расшарить кусок памяти и перекидывать между процессами такой же указатель, не?

Тогда потеряется «безопасность», драйвера смогут портить расшаренную память друг другу. А вообще да, можно расшарить память, в линуксе так и сделано — у всех модулей ядра вся память расшарена. :)

Мне достаточно того, что у меня эта дрянь не работает. Появится под 64 бита — потестим.

Ссылка на 64-битный эксплоит на десяток постов выше.

birdiebutthurt

subj

Ядра новее 3.2 кто-то использует? O_o

«сервис пак» за номером .2 дискредитировал убунту 12.04 как LTS дистрибутив.

А что там было такой страшное? (у меня 12.04 только на одном ноуте, там легко не заметить гадости)

Какой батхёрт у виндузятника может быть из-за дыры в линупсе?

Ссылка на 64-битный эксплоит на десяток постов выше.

Прошу прощения, но до сего момента имел дело только с готовыми сырцами с включенным makefile. Что с этим делать, не подскажете?

поменялись мажорные (!!!) версии ядра (!!!), иксов и месы. Причем прилетело EOL ядро.

3.6.11 — у меня.<br> 3.4.9 — у жены.<br> 3.7.9 — на общем ноуте :).<br>

Ясно, хотели, видать, порадовать пользователей новых ноутов...

Конечно плевать - я админ локалхоста. Мои многочисленные сообщения в разных темах форума написаны просто от желания всё попробовать и всему научиться.

http://pastebin.com/a9BrSGFY

Я не программер, и что с этим куском кода делать, который по ссылке, понятия не имею ни малейшего. Объясните, плз, что нужно, чтобы довести его до исполнимого состояния?

Я не программер, и что с этим куском кода делать, который по ссылке, понятия не имею ни малейшего.

Как обычно: скачать, скомпилить, запустить. Если по-юзерски: ткнуть на Download, cохранить в файл archer.c, перейти в каталог, в котором был сохранен этот файл и выполнить:

gcc -o archer archer.c

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

Работать будет, если будет, только на 64-битной системе.

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

Этого не скажешь про web-сервера со всякими cms...

У тебя с датой что то

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

Блин, Линуксу уже более 20 лет, а вирус без красноглазия всё еще не запустить! Да и с красноглазием не всегда... Обидно! :(

Конечно плевать - я админ локалхоста. Мои многочисленные сообщения в разных темах форума написаны просто от желания всё попробовать и всему научиться.

Ну прям как я =)

Хотите использовать его в 64-битном ядре — подберите другие адреса и исправьте эксплоит.

Кстати, попробуйте вариант sd: http://pastebin.com/a9BrSGFY Он вообще-то под арч писался, но 64-битный.

О, вот это на 3.7.7-gentoo работает. Ну наконец-то хоть одну уязвимость у себя завёл!

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

Я бы не стал этим гордится.

Проще перезагрузить машину, что делают 99.99999%.

Когда у тебя сервер собран из старенького desktop'ного компа сына, то проще. А если это серверная мать с отдельной платой рэйд-контроллера, то только на всякие самопроверки ещё до старта загрузчика ОС уходит порядка 2-х минут.

Я бы не стал этим гордится.

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

А если это серверная мать с отдельной платой рэйд-контроллера, то только на всякие самопроверки ещё до старта загрузчика ОС уходит порядка 2-х минут.

Ну и? Хоть 10 минут.

Я бы не стал гордится его использованием.

Ты не понимаешь. Надо его просто использовать, а не гордится.

Ибо костыль и бесперебойность надо обеспечивать другими способами.

Какая бесперебойность? Ядро обновлять надо, вообще-то, как-то. И не надо говорить про HA. kexec несравнимо дешевле HA в таких случаях.

Ну и? Хоть 10 минут.

И пользователи ждут инета или сервиса 10 минут.

Надо его просто использовать

Зачем его использовать?

Ядро обновлять надо, вообще-то, как-то.

По очереди сервера перезагружать религия не позволяет?

И пользователи ждут инета или сервиса 10 минут.

Пользователей обслуживает один сервер? Тогда можно сделать соответствующие выводы о компетентности конторы/админов ...

Зачем его использовать?

Алексей, хватит уже чепуху писать. kexec удобен, потому что позволяет делать ребут много быстрее обычного способа. Это существует, это факт, это работает, это удобно. Делать ребут быстрее, а не медленнее это однозначно плюс, а не минус. Далее.

Пользователей обслуживает один сервер? Тогда можно сделать соответствующие выводы о компетентности конторы/админов ...

Не все в москвах работают. Съезди в отпуск не в Турцию, а за МКАД, для разнообразия. Погляди что по чём. Мы тут миллионами не ворочаем, что бы делать полное резервирование всего абсолютно сетевого оборудования. Я, вообще, мало контор видел, у которых, хотя бы, полное резервирование активного оборудования. Про пассивку молчу, вообще. У тебя полное резервирование?

Работать будет

Подтверждаю, дает рутовый шелл. 3.7.8-202.fc18.x86_64

gcc -o archer archer.c

Вот именно это я спрашивал. Кстати, при запуске ошибка сегментирования, больше ничего.

Рутовый шелл не открывается.

Точно, вышло уже, а я и не заметил.

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

Это вряд ли — нужно чтобы там была такая функция и покорежились именно её данные. В драйвере вебки и вообще абсолютном большинстве ядерного кода такого не будет.

Собственно, из того же процесса код и дергается. :)

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

Тогда потеряется «безопасность», драйвера смогут портить расшаренную память друг другу.

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

Это вряд ли — нужно чтобы там была такая функция и покорежились именно её данные. В драйвере вебки и вообще абсолютном большинстве ядерного кода такого не будет.

Верно. И это не зависит от микроядерности. В монолитном ядре все точно так же.

Вместе с микроядерностью это сильно осложнит поиски куда воткнуть payload.

Все равно его можно передать вместе с сообщением, или оставить где-то в shared memory. Усложнение не решит проблему. mmap_min_addr в линуксах тоже осложняет размещение payload-а, но не защищает от всех эксплоитов.

Эта сложность в написании эксплоита дается ценой более сложного и медленного кода драйверов. Стоит ли оно того?

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

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

PS: Мы тут разошлись по теме shared memory, а ведь она в minix-е появилась совсем недавно, где-то в середние 3й версии, и ее пока что почти никто не использует, вероятно, потому что это слишком усложняет и без того непростое взаимодействие между системными процессами.

Не, ну я, как бы, тоже бубунты не особо. Но

поменялись мажорные (!!!) версии ядра (!!!), иксов и месы.

И что?

Причем прилетело EOL ядро.

И что?

Ты ври, да не завирайся. Существующие инсталляции ни мажорную версию ядра, ни Х не обновят, обновление коснется только новые. Ну а кто в погоне за циферками вручную обновится и все поломает — ССЗБ.

И что?

Заимели две частично несовместимые версии 12.04 убунты.

И что?

То, что они «ниасилят» и через полгода-год у нас опять будет «счастье».

Это тоже плохо. Правильный путь — бекпортить драйвера в ядро 3.2.