The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Критическая уязвимость в загрузчике GRUB2, позволяющая обойти UEFI Secure Boot, opennews (?), 30-Июл-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


47. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +18 +/
Сообщение от Аноним (47), 30-Июл-20, 07:44 
1.
> Уязвимость проявляется при разборе содержимого файла конфигурации grub.cfg, который обычно размещается в разделе ESP (EFI System Partition) и может быть отредактирован атакующим, имеющим права администратора, без нарушения целостности подписанных исполняемых файлов shim и GRUB2.

https://www.gnu.org/software/grub/manual/grub/grub.html#Usin...

У меня ВСЕ модули и ВСЕ настройки grub, включая grub.cfg и прочие которые он подгружает подписаны, так же как и ВСЕ ядра и инитрд. Не подписанный файл или с плохой цифровой подписью grub незагрузит и может прервать загрузку системы: set check_signatures=enforce .

Если grub.cfg изменить, то уязвимость не проявится, grub проверит цифровую подпись, увидеть что файл плохой и не будет его подгружать. Цепочку доверия и верификации между secure boot и IMA/EVM GRUB не нарушит.

Значит "уважаемая" RedHat опять что-то мутит...

PS:
У grub2 всеже есть баг или фичя:
1. Обнаружив плохую подпись или ее отсутствие grub не остановит загрузку, просто не будет загружать данный файл, и если возможно продолжит загрузку. Например в grub.cfg можно с помощью configfile включать другие конфигурационные файлы (https://www.gnu.org/software/grub/manual/grub/grub.html#Embe...) и если изменить их то grub.cfg отработает нормально но без загрузки измененного файла.
2. Если загрузка таки невозможна grub2 вываливается в рутовую "рескуэ" консоль где можно вводить ЛЮБЫЕ команды, включая: set check_signatures=no и дальше грузить все что захочешь!!! Я лично не раз этим пользовался чтобы прервать доверительную сертифицированный цепочку между secure boot и IMA/EVM. Баг это или фичя такая? В любом случае надо или отдельно от стандартного пароля grub (в core.img) защищать вываливание в консоль граба паролем или иметь опцию на подобие set rescue_console=off и устанавливать ее в переменные окружения как и check_signatures в grub core.img который верифицируется secure boot.

2.
> В большинстве Linux-дистрибутивов для верифицированной загрузки используется небольшая прослойка shim, заверенная цифровой подписью Microsoft.

С secure boot ВСЕ чужие публичные ключи должны удалятся. Это незыблемое требование Integrity. Вы сами, лично, должны создать свой ключ для secure boot и подписывать им grub core.img в котором находятся установленные переменные и публичный ключ для проверки подписей модулей grub, его настроек, а также ядер и инитрд. Наличие любого чужого публичного ключа, даже, такой уважаемой фирмы как M$, в secure boot неприемлимо!

Ответить | Правка | Наверх | Cообщить модератору

49. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +3 +/
Сообщение от Аноним (49), 30-Июл-20, 08:09 
> Значит "уважаемая" RedHat опять что-то мутит...

100% хотят дрянь типа systemd в grub засунуть под предлогом исправления из пальца высосанной, практично не реализуемой проблемы.

Ответить | Правка | Наверх | Cообщить модератору

81. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +4 +/
Сообщение от Аноним (81), 30-Июл-20, 09:36 
> Проблема решается только обновлением в системе списка отозванных сертификатов (dbx, UEFI Revocation List), но в этом случае будет потеряна возможность использования старых установочных носителей c Linux. Некоторые производители оборудования уже включили в свои прошивки обновлённый список отозванных сертификатов, на таких системах в режиме UEFI Secure Boot можно будет загрузить только обновлённые сборки дистрибутивов Linux.

А может дрянь не в сам grub совать будут, а в "обновлённые сборки дистрибутивов Linux" уже засунули... А чтобы со старых, чистых образов не грузились и не ставили чистую систему отозвали в UEFI старые ключи!

RedHat с systemd любимого Потеринга начало жесткое наступление.

Ответить | Правка | Наверх | Cообщить модератору

91. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +2 +/
Сообщение от Аноним (91), 30-Июл-20, 10:22 
Уже есть systemd boot.
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

96. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  –1 +/
Сообщение от Анноним (?), 30-Июл-20, 10:34 
До GNU/Systemd осталось немного )
Ответить | Правка | Наверх | Cообщить модератору

98. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  –2 +/
Сообщение от anonymous (??), 30-Июл-20, 10:39 
Обсуждаю с коллегами варианты защиты, и ребята говорят, что надо внедрять systemd bootloader :)
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

136. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +2 +/
Сообщение от anonom (?), 30-Июл-20, 14:56 
лавров.jpg
Ответить | Правка | Наверх | Cообщить модератору

174. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 30-Июл-20, 19:02 
А если откинуть эмоции, то технические аргументы какие forward-нуть?
Ответить | Правка | Наверх | Cообщить модератору

219. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (219), 31-Июл-20, 11:17 
Форкнуть хотели сказать?

Описанная уязвимость boothole практично нереализуема! У меня ее нет!

Рассмотривалм варианты:
1. с шифрованым /boot
2. с шифрованым /boot на загрузочной флешке
3. с шифрованым заглавием LUCS на загрузочной флешке.

Заметь, мало того, что grub проверит все подписи, так еще шифрование /boot не даст ничего в нем поменять.

Ответить | Правка | Наверх | Cообщить модератору

238. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 31-Июл-20, 14:39 
> шифрование /boot

А ключ для шифрования откуда берётся? Вручную вводится? Или из TPM?

А проблема реализуется очень просто на машинах, где запрещено шифрование данных из-за проблем с performance: просто грузишься по сети с побитым grub.cfg (который обычно не измеряется, ибо слишком динамичный) и получаешь полный контроль над системой с правильными значениями в TPM :)

Ответить | Правка | Наверх | Cообщить модератору

239. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 31-Июл-20, 14:39 
Да даже если разрешено шифрование с ключом в TPM -- та же проблема.
Ответить | Правка | Наверх | Cообщить модератору

241. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (241), 31-Июл-20, 14:56 
Значит так ребята.

Давайте версии используемого вами grub пишите и дистрибутива!

Ответить | Правка | Наверх | Cообщить модератору

240. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (241), 31-Июл-20, 14:53 
Не должно быть проблем ни с ручным вводом пароля ни с ключом.

Измененный grub.cfg не загрузится, подпись не прокатит!!!

Можно и Libre BOOT шифровать диск, он тоже умеет.

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

253. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 31-Июл-20, 19:59 
> ни с ручным вводом пароля

Когда у тебя миллион серверов, это уже становится проблемным.

А про ключик из TPM я сказал чуть выше.

> Libre BOOT

Не работает на современных серверных платформах.

Ответить | Правка | Наверх | Cообщить модератору

255. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (255), 01-Авг-20, 07:16 
> А про ключик из TPM я сказал чуть выше.

С каким конкретно TPM и какая конкретно версия GRYB не работает?

> Когда у тебя миллион серверов, это уже становится проблемным.
>> Libre BOOT
> Не работает на современных серверных платформах.

Если лям серваков то можно и Libreboot на них портировать.

Ответить | Правка | Наверх | Cообщить модератору

258. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (258), 01-Авг-20, 08:09 
> Если лям серваков то можно и Libreboot на них портировать.

Или coreboot затрояненый проприетарные блобами обучить шифровать /boot. Портировать поддержку LUKS с GRUB2 или LibreBOOT не сложная задача.

Ответить | Правка | Наверх | Cообщить модератору

264. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 01-Авг-20, 10:12 
> Или coreboot затрояненый проприетарные блобами обучить шифровать /boot. Портировать поддержку LUKS с GRUB2 или LibreBOOT не сложная задача.

Не могу распарсить написанное ^ :(

Ответить | Правка | Наверх | Cообщить модератору

288. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (288), 03-Авг-20, 14:16 
Coreboot обучить шифровать /boot портировав в него поддержку LUKS с GRUB2 или LibreBOOT.
Ответить | Правка | Наверх | Cообщить модератору

263. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от anonymous (??), 01-Авг-20, 10:09 
> С каким конкретно TPM и какая конкретно версия GRYB не работает?

Почему не работает? Работает. Просто тут выбор:
1. Либо запретить менять конфиг grub, иначе потеряешь доступ к диску. А это трудновыполнимое требование (всё же постоянно надо что-то менять и улучшать).
2. Либо не измерять конфиг grub. Тогда обсуждаемая уязвимость позволяет получить ключик для шифрования диска какой-нибудь malware.

Что конкретно предлагаете выбрать? :)

> Если лям серваков то можно и Libreboot на них портировать.

Очень похожий проект у нас тоже есть, но до полномасштабного запуска ещё несколько лет. Там есть множество сложностей, которые, к сожалению, попадают под NDA от Intel :(

Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

289. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (288), 03-Авг-20, 14:29 
> Что конкретно предлагаете выбрать? :)

Не понял вашей политики организации изменения конфигурации grub.

Для изменения конфигурации надо:
1. Расшифровать и примонтировать /boot
2. Изменить конфиг
3. Изменить подпись конфига
4. Отмонтировать и закрыть /boot

Как обсуждаемая уязвимость поможет получить ключ от шифрования диска когда grub.cfg подписан и его подпись проверяется при загрузке? Этой уязвимости практично не существует.

Ответить | Правка | Наверх | Cообщить модератору

308. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (308), 18-Авг-20, 14:54 
> полный контроль над системой с правильными значениями в TPM :)

Нет такого в природе, подпись grub.cfg проверяется и "побитого" GRUB не загрузит. Кроме того в TPM GRUB пишет все свои действия, которые изменяют его значение:

https://www.gnu.org/software/grub/manual/grub/grub.html#Meas...
"If the tpm module is loaded and the platform has a Trusted Platform Module installed, GRUB will log each command executed and each file loaded into the TPM event log and extend the PCR values in the TPM correspondingly."

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

231. "Практично уязвимости CVE-2020-10713 (BootHole) не существует!!!"  +/
Сообщение от Аноним (231), 31-Июл-20, 13:24 
Он курящий.
Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

50. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (49), 30-Июл-20, 08:15 
s/сертифицированный цепочку/вериытцированну цепочку/

Вражеский спелчекер херит смысл.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

123. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (231), 30-Июл-20, 13:05 
Смысла нет, есть цель.
Ответить | Правка | Наверх | Cообщить модератору

102. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от Аноним (102), 30-Июл-20, 11:36 
> У меня ВСЕ модули и ВСЕ настройки grub, включая grub.cfg и прочие которые он подгружает подписаны

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

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

207. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (207), 31-Июл-20, 08:47 
https://www.gnu.org/software/grub/manual/grub/grub.html#Usin...

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

Подписывать надо только если меняете ядро, инитрд, grub или его конфиги.

Обновление и настройка организованы так чтобы в рабочей системе приватных ключей не было.

Если ключ граб изменился то измененный надо добавить в core.img, grub-install это делает. И потом подписать ключом UEFI.

Ответить | Правка | Наверх | Cообщить модератору

230. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (230), 31-Июл-20, 12:59 
https://www.linux.org.ru/forum/admin/15742224?cid=15744272
Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

157. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от олооло (?), 30-Июл-20, 16:20 
Какой дистр? Что мешает на компе прописать зловредные ключи при наличии физ доступа?
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

216. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (219), 31-Июл-20, 10:46 
> Какой дистр?

Сам себе дистростроитель. Свой дистр свои правила.

Сегодня нет популярных дистров с полностью включенной Integrity.

Спросите Мишу пусть нам расскажет почему в ALT Linux политика IMA проверяет только модули ядра и прочие критические элементы, а не всю систему: /bin /sbin /lib /etc /usr ?

> Что мешает на компе прописать зловредные ключи при наличии физ доступа?

В каком месте собираешься подставить зловредный ключ:
https://www.opennet.ru/openforum/vsluhforumID3/121426.html#62
Этот зловредный ключ должен иметь подпись ключа с предыдущего этапа загрузки.

Есть такое понятие "верифицированная цепочка загрузки".

Ответить | Правка | Наверх | Cообщить модератору

218. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +1 +/
Сообщение от Аноним (219), 31-Июл-20, 11:08 
> У grub2 всеже есть баг или фичя:
> Если загрузка таки невозможна grub2 вываливается в рутовую "рескуэ" консоль где можно вводить ЛЮБЫЕ команды

Документированная фичя:

https://www.gnu.org/software/grub/manual/grub/grub.html#GRUB...

https://www.gnu.org/software/grub/manual/grub/grub.html#Usin...

"Note that signature checking does not prevent an attacker with (serial, physical, ...) console access from dropping manually to the GRUB console and executing:

set check_signatures=no

To prevent this, password-protection (see Authentication and authorisation) is essential. Note that even with GRUB password protection, GRUB itself cannot prevent someone with physical access to the machine from altering that machine’s firmware (e.g., Coreboot or BIOS) configuration to cause the machine to boot from a different (attacker-controlled) device. GRUB is at best only one link in a secure boot chain."

Дыра полудокументирована. Внимание пароль на консоль grub спрашивает только после загрузки grub.cfg где этот пароль находится. До загрузки grub.cfg о паролях grub  ничего не знает и соответственно спрашивать не будет!!!

Эту фичу надо профиксить через добавление переменной окружения: rescue_console=on/off она реально удобная и иногда крайне нужная.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

257. "Критическая уязвимость в загрузчике GRUB2, позволяющая обойт..."  +/
Сообщение от Аноним (258), 01-Авг-20, 08:03 
Наверно все же лучшим решением будет перенос пароля с grub.cfg в grub core.img. И всегда при переходе в rescue консоль запрашивать этот пароль.

Здесь "уязвимость"/фичя того же порядка как shell busybox в initrd или режим single user mode в Linux.

Если диски /boot и / шифрованы, то никто чужой этими фичами воспользовался не сможет.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру