Уязвимость CVE-2016-4484 в cryptsetup

Да ну, пойду писать свою ОС.

в лило такой херни бы не было! но нет, нам нужен модный граб, модный вейланд, модный системдэ...

лило... как много в этом слове...

физический доступ такой физический..

Зато исследователи по ссылке, как я понял, хотят полностью сломать возможность доступа к аварийному shell'у при работе фазы запроса ввода пароля. Лишив пользователя возможности посмотреть что пошло не так.

Аварийный шелл - хорошо, но пароль рута, по-твоему, уже не надо спрашивать для него?

А, хотя дошло... Откуда его ещё брать этот пароль, если диски не подмонтированы.

Но тут получается проблема в том, что в груб или uefi может стоять пароль. А тут нет.

Хипстеры вещают, что граб уже не модный. Модный по версии хипстеров rEFInd .

Efistub же, твои хипстеры уже не в теме.

но пароль рута, по-твоему, уже не надо спрашивать для него?

Дык, а где его там хранить тогда ? В аварийный шелл, что ещё и PAM тянуть весь тогда ? С хешированным паролем из /etc/shadow ? А ещё потребуется тогда и весь инструментарий для логина. Возможность для злоумышленника упереть рутовый пароль (пускай и хешированный) прямо из initrd, когда вся остальная система зашифрована - вот это уже настоящая дыра куда серьезнее.

ИМХО, самое актуальное решение проблемы - предложенные по ссылке workaround'ы, (и параметр rd.shell в dracut'е): не смог загрузиться из-за какой-то проблемы, включил шелл и глянул что пошло не так.

Не дочитал исправления когда писал ответ.

Вообще, получить какую-то защиту от доступа к редактированию конфигурации загрузки в том-же GRUB'e - можно, используя загрузку ведра напрямую из UEFI (оно так умеет). Можно сделать несколько пунктов меню со включенной и выключенной отладкой. А доступ в UEFI - запаролить.

Вот я сейчас не помню, можно поставить в груб (uefi) запрет (или запаролить) на свою модификацию при логине, чтобы нельзя было записать init=/bin/sh ?

Если можно, а cryptsetup вызовет шелл, то нехорошо.

То есть, твоё мнение, что обсуждаемая уязвимость на самом деле не даёт абсолютно ничего нового для взлома, для того, кто и так имеет права и пароли грузить компьютер?

Да: https://itshaman.ru/articles/14/password-grub#21

Примерно так. Есть ведь и другие способы вызвать «отказ» в загрузке компуктера при наличии физического доступа к нему, и получить аварийный shell. Проблема в самом наличии аварийного шелла. Для параноиков должна быть опция глобального отключения такого шелла, либо полного его исключения их initrd. Именно в этом направлении и надо работать. Скрипты cryptsetup отрабатывают как положено: в случае если они не смогли сделать что нужно - управление передается дальше, чтобы была возможность что-то предпринять на следующем этапе. Такова и была изначальная идея архитектуры всех этих dracut'ов и <что там за велосипед используется для создания initrd в дебиане>. Модификация cryptsetup предложенным образом - это и есть самый настоящий костыль, так как нарушает изначальную архитектуру. К чему со временем приводят нагромождения костылей, думаю, можно не объяснять.

К тому-же если пользователь озабочен возможностью незаметного для него физического доступа к initrd или конфигурации загрузчика, то нужно не костыли мастерить вроде модификации скриптов для cryptsetup, а разрабатывать этот функционал в самих загрузчиках, использовать механизмы UEFI типа secure boot, цифровые подписи и прочее.

а если нет busybox?

у меня зашифрован /, что теперь делать?

Опять кому-то кот компьютер взломал?

Arch Linux users are not affected by this issue

фух http://news.softpedia.com/news/major-cryptsetup-vulnerability-affects-some-lu...

Вот как такое могло получиться? Похоже на специально оставленный бэкдор.

А кто-то BSD называет самой безопасной системой. Любая система становится дырявой, как только поставишь софт. Голый Linux так же безопасен, как и BSD. И вот те на - софт, который должен обеспечивать безопасность, содержит эпичные бэкдоры, которые способны уничтожить целый бизнес.

Модный по версии хипстеров rEFInd .

Он как лило, его надо после каждого чиха и пука переустанавливать.

Да ты подожди, завтра в systemd такую дырень найдут! Мы же с вами умные люди и понимаем, что если о дыре никто не знает, то это не значит, что её нет.

Но ведь это уязвимость не в cryptsetup, а в скриптах инициализации дебиана.

Предлагаешь сделать systemd закрытым?

Вот как такое могло получиться? Похоже на специально оставленный бэкдор.

Похоже на линакс решето

Плачет по таким программистам.

Да наверняка кгб внедрило бэкдор чтобы ломать компьютеры на выборах в США. Ведь линакс оперсорсный а значит любой злоумышленник может послать патч с бэкдором

А надо именно 70? Я 120, для верности.

Возможность для злоумышленника упереть рутовый пароль (пускай и хешированный) прямо из initrd, когда вся остальная система зашифрована - вот это уже настоящая дыра куда серьезнее.

initrd нужно размещать на шифрованном разделе. (да, это реально)

да, это реально

Ну, для загрузки системы нужно всего-лишь загрузить в память ядро, initrd и запустить его выполнение определенным образом. Откуда загрузчик будет доставать эти файлы - уже совершенно другой вопрос. GRUB очень функциональный, наверняка его можно заставить доставать эти два файла и из шифрованного раздела напрямую. Вопрос в том, что геморроя многовато с настройкой будет.

У меня зашифрован диск. Дистрибутив - Fedora 24 (GNOME). При зажатии кнопки на 10-15 секунд - выкидывает в шелл. Создаются папки. После перезагрузки этих папок нет. Хотел удалить папку /root для эксперимента, но как-то боязно: вдруг создавать папки нельзя, а удалять можно?)) Короче, хоть это и баг, наверное, но уязвимостью это вряд ли назовёшь, т.к. папки /home в том шелле нет.

initrd нужно размещать на шифрованном разделе

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

Там где допустимо использовать аварийный шелл - не требуется наличие дополнительной проверки логина, и соответственно не нужно мучаться с хранением initrd там на шифрованном разделе. Там где аварийный шелл использовать опасно - его нужно полностью отключать, а не делать костыли которые всё-равно за пару секунд обходятся (например, редактированием параметров загрузки в GRUB'е прямо перед непосредственной загрузкой системы).

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

Заинтересовался, как же долбя Enter можно подобрать ключи? По ссылке:

root initramfs shell
Obviously, the system partition is encrypted and it is not possible to decrypt it

Расходимся.

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

У атакующего физический доступ к машине, он может делать что угодно и без этого бага.

Короче, хоть это и баг, наверное, но уязвимостью это вряд ли назовёшь, т.к. папки /home в том шелле нет.

Ну откуда бы там /home взялась? Разве что на tmpfs.

А как убедиться, если даже df не работает? Fdisk, правда, не пробовал. Но многие команды не работают. Даже whoami. По-моему, это какой-то гон про «уязвимость». Уязвимость - это когда ты получаешь контроль и можешь контролировать РЕАЛЬНУЮ систему, а не её псевдообраз.

он может делать что угодно и без этого бага.

Мало того, он это может сделать куда быстрее и не ждать необходимые 10-120 секунд.

cat /proc/mounts

cat /proc/self/mounts

mount

в зависимости от того, какие бинарники и файлы есть у вас в initrd - способы могут быть разные.

если даже df не работает? Fdisk, правда, не пробовал. Но многие команды не работают. Даже whoami.

Ещё раз. Это аварийный shell, который находится в образе initrd со скриптами первоначальной загрузки. Какие утилиты туда разрабы вашего дистра положат, такие вам и будут доступны. Обычно там самый минимум.

Это аварийный shell

Но в общем да, можно представить себе юзкейсы, где наличие busybox в initrd нежелательно.
Типа банкомат не смог перезагрузиться, а юзернейм подошёл и потёр разделы.

Думаю, что поскольку этих граждан с бронированными банкоматами немного, пусть они сами себе initrd собирают.

Нет, корень был ненастоящим. И это назвали «уязвимостью»... ну-ну) Скорее, баг - причём некритичный, ни на что особо не влияющий. Кстати, сеанс ограничен таймаутом. Через минуту или две система начинает заваливать экран сообщениями о таймауте - дальнейшее использование шелла невозможно.

поскольку этих граждан с бронированными банкоматами немного, пусть они сами себе initrd собирают

Я вижу ещё и применение на предприятиях, во всяком ынтерпрайзе и прочее. Так что смысл добавить в популярные генераторы initrd возможность собирать образ без возможности уйти в шелл - есть. Плодить костыли в штатно работающий cryptsetup - нет. Надеюсь, что CVE из новости завернут, а авторов всюду забанят от греха подальше: у нас в мире линукса и без них костылей навалом уже.

Скорее, баг

Это вообще не баг. Это штатная работа скриптов инициализации. У тех «исследователей» просто осеннее обострение паранойи началось.

дальнейшее использование шелла невозможно.

А вся суть этого шелла - быстро глянуть в dmesg и понять что за фигня приключилась. Для большего он и не пригоден, если только busybox туда полноценный не пихать, конечно.

В общем, как обычно, расходимся - нас нае... обманули.

граб уже не модный

Граб уже не нужный. EFI наше все.

 ~ % grep -i crypt /etc/default/grub
GRUB_ENABLE_CRYPTODISK=y

Это вообще вся настройка, не считая вызова update-grub.

Ваше всё годится только для запуска полноценного загрузчика.

Опять?

Миллионы зорких глаз двоечников

Это неприятно

Проиграл.

А что, собственно, произойдет, если ввести неправильно пароль максимальное количество попыток (не знаю сколько в debian'е).
Скорее всего вывалится так же само в rescue shell.
Поправьте, если не прав.

Это неприятно

Проиграл.

Классика же:

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

Да, должно быть так по-идее, надо смотреть тот самый скрипт.

А ты хочешь сказать что подобное невозможно на языке программирования, на котором написан systemd(толстый намек, но всё же)? :-)