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

Мда…

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

Дебиан и его потомки теперь решето?

прям по следам груба.

а я уже и не удивляюсь

#

#

Тюрьма?

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

Дебиан и его потомки теперь решето?

Красношапка/Центовоз с Федориногоре тоже подвержены этой уязвимости.

прочитал

С большой вероятностью, уязвимы все системы, основывающиеся на Debian и использующие cryptsetup

как

Уязвимы все системы, основывающиеся на Debian, использующие cryptsetup

старею.

Однако решето. И они повсюду. Печаль. Ждём патчей.

По ссылке рассказано как пропатчить. Там надо отредактировать некоторые стартовые скрипты.

Видимо, несчастный уснул на Enter при попытке угадать пароль, а тут такое счастье

Даже не верится

Ну да. Наверняка срабатывало по времени, из расчёта «какой дебил зажмёт будет это делать больше минуты»

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

Ну вот заметили же.

шерето

Мне вот тоже очень интересно, как такие баги находят? Неужели ...

А вдруг экспериментальным путем заметили, а не чтением кода.

То есть для эксплуатации нужно иметь физический доступ к машине, это раз. Доступны оказываются только не зашифрованные разделы, это два. И в чём тут, позвольте спросить, уязвимость, если при выполнении пунктов 1 и 2 всё то же самое можно провернуть, загрузив машину с любого Live CD?

Подождите, куда он установит кейлоггер? В загрузчик, чтобы этот пароль стыбзить?

то же самое можно провернуть, загрузив машину с любого Live CD

Загрузка только с HDD, пароль на настройки биоса. Вытаскивание батарейки для сброса — это уже другой уровень физического доступа.

Ну не скажи, не всегда можно что-то воткнуть для такой загрузки.

сотрудник ушел на обед, быстренько зажал ентер, посмотрел историю броузера котиков, отжал ентер обратно

profit :)

но как?

это же не уязвимость, это шерето. такое можно разве что специально сделать.

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

Ну ок. Злоумышленник попадает в busybox от initramfs. Казалось-бы что ему мешает провести замену initramfs(на версию с кейлогером) или скопировать зашифрованный раздел с помощью livecd/livedvd не говоря уже о том, что имея локальный доступ можно тупо спереть диск.

Да, ситуация неприятная, но не фатальная.

держал 120 секунд, не работает. ЧЯДНТ?

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

Наглядный пример шеллоговна. И вы после этого будете говорить, что systemd не нужен?

Права root за 70 секунд

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

Для хомяков, возможно, единственный реально необходимый юзкейс — шифрование диска на ноутах, чтоб при утере/краже никто их хоумпорн не смотрел. Для серьёзных применений никто на одно только средство не полагается, там ещё будут всякие политики в области physical security. В этих двух случаях баг ни на что не повлияет. То есть фиксить надо, но для паники в стиле первых комментов повода нет совершенно.

ты совсем наркоман или Поттеринг уже написал systemd-initramfs?

Это не баг, а нужная фича, а вендофанатики опять негодуют что в их говносистеме такого никогда не будет.

или Поттеринг уже написал systemd-initramfs

О чём и речь — уже и давно.

workstation ~ # eix -I cryptsetup
No matches found

void ~ # xbps-query -s cryptsetup
void ~ #

значит не нужно.

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

Поддерживает. Нет, не тот же.

https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption

Ну давай ссылку, посмотрим.

Наглядный пример шеллоговна. И вы после этого будете говорить, что systemd не нужен?

Наглядный пример человека, который не понимает о чём пишет.

На что тебе дать ссылку? На отсутствующее в systemd шеллоговно?

Приятно с вами познакомится

Наглядный пример человека, который не понимает о чём пишет.

Выдвигая претензию — обосновывай.

На то как этот systemd-говно настроить заместо классического initramfs

Лол, хорошо хоть не расшифровать.

Зато можно зашифровать ещё раз)

Это да :)

Закладочку чью-то спалили ;(

Gentoo, не работает.

несчастный уснул на Enter при попытке угадать пароль, а тут такое счастье

Какое? что он в итоге может слить образ и все, либо запортить раздел. По моему это самая классическая «атака», как ее до сихпор не нашли, вот вопрос... Толи оно совсем не нужное и используется только дома либо все скрысили...

точно 70 секунд держал? может ещё раз попробуешь?

Не знаю, где ты панику увидел. Там скорее недоумение по поводу нелепости бага.

Пффф.... тоже мне нашли уязвимость. Специально для всёпропальщиков, не ходящих по ссылкам, объясняю как оно работает.

Во время работы initrd (как дебиановского, так и модномолодёжного dracut), есть фаза инициализации шифрованных устройств, при которой либо запрашивается пароль, либо производится попытка активации устройства с помощью ключевого файла. В случае если после какого-то количества вводов пароля разлочить устройство не удалось, система пытается продолжить загрузку без него - так как по логике, предполагается, видимо, что мы не обязательно пытаемся разблокировать именно корневой раздел. Дальнейший этап загрузки ожидает появление финального корневого раздела какое-то время. И если шифрованный раздел был корневым, то разумеется - через настроенное там время таймаута, раздел не обнаруживается. И всё, на этом этапе initrd просто выкидывает пользователя в встроенный в него «аварийный shell», чтобы пользователь сам мог как-то диагностировать проблему. Вот и вся уязвимость.

Это между прочим, стандартное поведение при любых ситуациях, когда на каком-то этапе в initrd загрузка не может быть продолжена (в данном случае, не было доступно устройство с корневым разделом), доступа к зашифрованным данным никто не получает, нормальных утилит для проведения какой-то худо-бедно нормальной атаки вроде установки кейлоггера - в таком шелле нет, с большой долей вероятности там даже не будет поддержки USB-дисков. Мало того, в dracut запуск аварийного shell'а можно отключить если передать параметр загрузки rd.shell=0.

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