юмор

Безопасная ОС Линукс

"Это какой-то... позор?"

Originally posted by dil at 0-day in GRUB2
Originally posted by malaya_zemlya at 0-day in GRUB2
Если кто не видел - в популярном загрузчике Grub2 обнаружена уязвимость, позволяющая обходить защиту паролем, и дающая полный доступ к шеллу.

Эксплоит: вместо введения пароля нажать на Backspace ровно 28 раз, а потом Enter

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

Если вместо ввода пароля нажимать на Backspace, то из-за пропущенной проверки программа заезжает за пределы буфера и начинает затирать нулями память с отрицательным смещением. Бывает.
В результате затирается стек, включая адрес возврата из текущей функции. Ок.
Соответственно, процессор прыгает на адрес 0, при чем в регистре esi остается текущая длина пароля, то есть -28.
По адресу 0, как водится, расположена таблица IVT, где лежат адреса обработчиков системных прерываний, но процессор ее сейчас интерпретирует не как адреса, в как исполняемый код. Оказывается, что в такой интерпретации IVT содержит функцию копирования блока памяти, где адрес, куда копировать, берется из регистра edi (он у нас установлен тоже в 0), а адрес откуда - из того самого регистра esi.
Получается, что функция начинает править собственный код и копировать данные из адреса -28 прямо поверх самой себя. Причем в цикле.
На первый раз портятся несколько инструкций в начале, но не критично.
На второй раз добавляются какие-то инструкции, меняющие содержимое стека,
А дальше... дальше появляется инструкция retw. Она берет со стека число и прыгает по обозначенному им адресу. А на стеке в этот момент лежит адрес встроенного шелла.

Занавес.

Нюанс -- нужен физический доступ к машине.
Физический -- это когда диск можно достать и вставить в свой комп. А тут нужен просто доступ к клавиатуре. Это может быть вообще через KVM over IP.
Ну, пожалуй, да.
Хотя у меня есть ощущение, что эксплойтабельность этой дырки сильно зависит и от платформы, и от версии компилятора, и от флагов оптимизации.
Прекрасно!
Люблю подобные штучки.
По ассоциации вспомнилась OS/2. Которая, при работе на 286 процессоре и при мультитаске дос-задачи, для переключения процессора из защищенного в реальный режим (виртуализации на 286 не было, дос-задачам был нужен реальный реальный режим) использовала контроллер клавиатуры (286 штатной команды выхода из защищенного режима не имел). А конкретно - просила этот самый контроллер сделать ресет процессору, перед этим что-то подшаманив то-ли с портами, то-ли с памятью, чтобы очнувшись после ресета процессор выполнил что надо, а не что обычно.
Силища :) Типа внешнего стека получалось....
Забавно, что примерно в то же время микрософт уже додумался до triple-fault reset (на тот момент недокументированного intel, но работавшего начиная с 286, и бывшего в десятки раз более быстрым), и даже его использовал.

В чуть более поздние времена, 386-486 и win95, был прикол, когда сотрудники интел на каком-то митинге поинтересовались у разработчиков винды, "может подскажете, что в первую очередь стоит ускорить в следующей версии процессора". Получили ответ "обработку исключения invalid opcode!", посмеялись хорошей шутке, разошлись. А погоняв уже у себя, в intel, win95 под профилёром, поняли что это была не шутка - win95 значительное время тратила на исполнение этих самых invalid opcode, потому что это оказалось самым быстрым способом переключения режимов - быстрее чем тот, что считался штатным у интел.

А уже сильно позже, когда нашли "баг F00F", на почти аппаратном уровне наглухо вешавший по-моему вообще все имевшиеся на тот момент процессоры intel - неважно, под какой операционкой этот "F00F" запускался - оказалось что. Всякие там линухи, бзди и прочие солярисы, а также NT всех сортов - вешались только в путь, при запуске от самого бесправного юзера. А вот win95 - вешалась не всегда. Как оказалось - именно за счет того, что штатно исполняла invalid opcode'ы в массовых количествах, что нарушало предусловия срабатывания F00F бага. Нормальные-то операционки "неправильные команды" обычно не выполняют... :-)