LINUX.ORG.RU

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

 , ,


3

2

Найденная уязвимость позволяет получить доступ к оболочке busybox с привилегиями администратора, если удерживать клавишу ввода около 70 секунд во время запроса пароля к зашифрованному тому.

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

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

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

★★★★

Проверено: anonymous_incognito ()
Последнее исправление: sudopacman (всего исправлений: 4)

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

snaf ★★★★★
()

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

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

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

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

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

прочитал

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

как

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

старею.

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

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

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

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

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

Mamin_simpotyaga
()

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

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

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

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

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

unt1tled ★★★★
()

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

Zenom ★★★
()

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

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

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

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

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

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

profit :)

unt1tled ★★★★
()

но как?

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

i36_zubov
()

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

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

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

Deleted
()

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

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

anonymous
()

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

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

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

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

Zenom ★★★
()
Последнее исправление: Zenom (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LinuxDebian ★★★★
()
Последнее исправление: LinuxDebian (всего исправлений: 1)
Ответ на: комментарий от Zenom

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

Psych218 ★★★★★
()

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

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

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

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

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