Все наверное уже читали и в курсе уязвимостей в GRUB2

Использую нормальный системд-бут, горя не знаю.

Использую нормальный системд-бут, горя не знаю.

Если уже система установлена?

Поменять, в арче это делается очень просто.

а если без uefi?

Системд-бут и груб друг другу не мешают

Здесь столько «но», что сама тема уже смешная.

Посмотрела на их Вики, вроде просто все. А на счёт загрузки сертификатов, что-то можете подсказать?

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

sbctl

Все наверное уже читали и в курсе уязвимостей в GRUB2

CVE-2020-14372
CVE-2020-25632
CVE-2020-27749
CVE-2020-27779
CVE-2021-20225
CVE-2021-20233

Это неиспользуемые уязвимости, эксплуатация которых бессмысленна, так как требует привелигированной консоли GRUB2. А если у взломщика будет привелигированная консоль, то он воспользуется документированной возможностью:

set check_signatures=no
insmod unsigned_bootkit

CVE-2020-25647 - если правда, то потенциально опасна и может потенциально использовался для загрузки bootkit-ов! Только с этой уязвимость надо что-то решать.

CVE-2021-3418 - не надо было обновляется с несуществующей «boothole»: А чё, никто не в курсе? Новая уязвимость линукса: BootHole (комментарий)

как загрузить список отозванных сертификатов (dbx) в прошивку UEFI?

На LORe учат в подсистеме Integrity использовать только свои ключи!

Все ключи M$ и прочих необходимо удалить и загрузить ключи созданные вами лично: https://habr.com/en/post/273497

PS: эта тема вас касается только если в вашем дистре поддерживается верификация модулей и настроек GRUB2 при загрузке.

ls /boot/*.sig

CVE-2020-25647 все равно возможно касается всех у кого на GRUB установлен хотябы пароль.

документированной возможностью

А это работает после того, как в GRUB недавно реализовали поддержку Lockdown по подобию ядра? В ядре оно реализовано столь основательно, что отключить можно только вырубив Secure Boot.

https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

"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."

Груб без пароля - сам по себе дырища.

Про Lockdown там ни слова. Эта фича ещё не в релизе. Если она сделана как в ядре Linux, то никакая консоль не поможет.

Ни разу не видел людей, которые используют пароли в Grub. Установка пароля в Grub бессмысленное действие. Обойти легко.

А без пароля это как дверь без замка.

Достаточно иметь параметр для отключения консоли:

set console=on/off

И установить эту переменную среды по умолчанию выключенной в core.img:

grub-editenv /boot/grub/grubenv set console=off

grub-install …

Не пойму вас, че так шивелитесь вокруг уязвимостей GRUB? У ваших дистрах разве включена проверка подписей? Дайте вывод:

cat /etc/*release; grep ‘check_signatures’ /boot/grub/grubenv

Установка пароля в Grub бессмысленное действие. Обойти легко.

И как?

SecureBoot с дефолтными ключами в принципе должен защищать только от буткитов, и всё
Super UEFIinSecureBoot Disk — запуск любых ОС и .efi-файлов с флешки без отключения UEFI Secure Boot

Это не совсем так. Дефолтные настройки никому не интересны, M$ и другие корпорация могут грузить все, а вы ничего: https://habr.com/en/post/273497

Допустим есть правильно настроенный Secure Boot, ТОЛЬКО с вашими ключами: PK, KEK, ISK и паролем суперпользователя. Тогда от буткитов защищены UEFI и начальный загрузчик (core.img если установлен GRUB) или вся система если подписанное ядро с инитрд и параметрами загрузки прошито в UEFI: https://wiki.archlinux.org/index.php/Systemd-boot#Preparing_a_unified_kernel_image

UEFI Secure Boot не защищает модули и настройки GRUB от буткитов, ядро с инитрд. Они должны быть защищены самим загрузчиком GRUB: https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

Не пойму вас, че так шивелитесь вокруг уязвимостей GRUB? У ваших дистрах разве включена проверка подписей? Дайте вывод:

cat /etc/*release; grep ‘check_signatures’ /boot/grub/grubenv

Вот:

[root@localhost aleksa]# cat /etc/*release; grep ‘check_signatures’ /boot/grub2/grubenv
CentOS Linux release 7.9.2009 (Core)
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.9.2009 (Core)
CentOS Linux release 7.9.2009 (Core)

PS: эта тема вас касается только если в вашем дистре поддерживается верификация модулей и настроек GRUB2 при загрузке.

ls /boot/*.sig

Если вывод пуст, то у вас нет верификации при загрузке GRUB.

CVE-2020-25647 все равно возможно касается всех у кого на GRUB установлен хотябы пароль.

[root@localhost aleksa]# ls /boot
config-3.10.0-1160.15.2.el7.x86_64
config-3.10.0-1160.el7.x86_64
efi
grub
grub2
initramfs-0-rescue-5e423eed65df41c084a90446459ee028.img
initramfs-3.10.0-1160.15.2.el7.x86_64.img
initramfs-3.10.0-1160.el7.x86_64.img
lost+found
symvers-3.10.0-1160.15.2.el7.x86_64.gz
symvers-3.10.0-1160.el7.x86_64.gz
System.map-3.10.0-1160.15.2.el7.x86_64
System.map-3.10.0-1160.el7.x86_64
vmlinuz-0-rescue-5e423eed65df41c084a90446459ee028
vmlinuz-3.10.0-1160.15.2.el7.x86_64
vmlinuz-3.10.0-1160.el7.x86_64

На GRUB пароль не ставила.

Прилетели обновления:

[root@localhost aleksa]# yum check-update
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.comnet.uz
 * epel: mirror.hoster.kz
 * extras: mirror.comnet.uz
 * updates: mirror.comnet.uz

bind-export-libs.x86_64              32:9.11.4-26.P2.el7_9.4             updates
grub2.x86_64                         1:2.02-0.87.el7.centos.2            updates
grub2-common.noarch                  1:2.02-0.87.el7.centos.2            updates
grub2-efi-x64.x86_64                 1:2.02-0.87.el7.centos.2            updates
grub2-pc.x86_64                      1:2.02-0.87.el7.centos.2            updates
grub2-pc-modules.noarch              1:2.02-0.87.el7.centos.2            updates
grub2-tools.x86_64                   1:2.02-0.87.el7.centos.2            updates
grub2-tools-extra.x86_64             1:2.02-0.87.el7.centos.2            updates
grub2-tools-minimal.x86_64           1:2.02-0.87.el7.centos.2            updates
microcode_ctl.x86_64                 2:2.1-73.8.el7_9                    updates

Какие мои дальнейшие действия? Просто накатить обновления и все?

Дефолтные настройки никому не интересны, M$ и другие корпорация могут грузить все, а вы ничего

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

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

ls /boot/*.sig

Должен выводить список «открепленных подписей»

cat /etc/*release; grep ‘check_signatures’ /boot/grub/grubenv

Последняя строка должна быть:

check_signatures=enforce

Если всего выше перечисленного нет, то и верификации загрузки в GRUB2 нет!

У настройках grub.cfg должны быть строки:

set superusers=«…»

password_pbkdf2 …

export superusers

У кого этих строк нет, пароля на GRUB консоль нет! И любой сможет отключить верификацию или загрузить нужное ему ядро с нужными параметрами!

У CentOS-7 верификации загрузки по умолчанию нет! В инсталлере CentOS-7 не реализована подсистема Integrity.

Какие мои дальнейшие действия? Просто накатить обновления и все?

Я лично считаю данные обновления вредоносными и призываю всех пользователей CentOS-7 их НЕ УСТАНАВЛИВАТЬ! И прошлые обновления с boothole также НЕ УСТАНАВЛИВАТЬ!

решетом будет считаться только если буткит загружается без вмешательства пользователя

Допустим вирь получил root доступ к системе, тогда он может прописать загрузку буткита прямо в …/grub.cfg примерно так:

cp bootkit /boot/… && echo ‘insmod bootkit’ >> …/grub.cfg

Буткит спокойно, автоматически и без участия пользователя, загрузится в виде модуля GRUB2 с вашими дефолтными настройками UEFI Secure Boot.

просто не подписывай дырявые версии GRUB

Пока страшных дыр в GRUB2 не вижу. Есть один кандидат CVE-2020-25647 насколько это эксплуатируемо не знаю.

GRUB2 очень хороший загрузчик, единственный загрузчик поддерживающий крыптографию и загрузку образов LiveCD/DVD лежащих на разделах диска, к этому можно добавить загрузку по сети, поддержку разных аппаратных платформ, включая arm64. Это кому-то мешает и просто хотят GRUB2 испортить выдумывая несуществующие и не эксплуатируемых уязвимости…

Я разве против? Это мадемуазель хочет обезопаситься

Фу, secure boot, его реально что-ли линуксоиды использовать уже начали? А уязвимость какая-то неполноценная, я правильно понимаю, что если ребутнутся с отключенным инетом,и никого к компу не подпускать, то не сработает?

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

Вообще, в последние годы наплодилось много людей, которые в ОС не разбираются, но начитались ерунды и наплодили CVE.

Этот пароль в подавляющем большинстве случаев не нужен.

Пароль на GRUB нужен чтобы нельзя было:

• изменить параметры загрузки ядра

• войти в консоль и загрузить другое ядро

• отключить верификацию по цифровым подписям

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

• если Secure Boot со своими ключами и уже не загрузится чужой носитель. Даже пароль админа в BIOS помешает загрузке

и сбросить пароль. А от защиты данных на жестком диске не защищает вообще.

• Шифруйте ВСЕ разделы диска чтобы никто там не лазил

Одного только пароля в GRUB не достаточно, а в комплексе с другими средствами пароль GRUB дает хорошую защиту.

пользуясь случаем, у меня вопрос к местным экспертам:

есть /boot раздел в FAT32, на нем лежит ядро, оно добавлено в загрузку с помощью efibootmgr. корень естественно не зашифрован, и все, чем чревато?