Недавно всплыло интересное сообщение - раскрыта информация об уязвимости (CVE-2023-4001) в патчах к загрузчику GRUB2 от компании Red Hat.Небольшое пояснение
Для защиты пунктов меню загрузки и командной строки менеджера GRUB можно установить пароль. Это дополнительная мера безопасности, которая может использоваться наряду с паролем BIOS/UEFI (например, для защиты компьютеров от непривилегированных пользователей, которые могут использовать физический доступ для загрузки другой операционной системы или для повышения привилегий в уже установленной ОС).
Функция защиты реализована в виде двух команд GRUB: "password" и "password_pbkdf2". При выполнении одной из этих команд с соответствующим набором аргументов создается пользователь с указанным паролем (или его хэшем). И только тем пользователям, которые указаны в переменной окружения "superusers", разрешено редактировать пункты меню загрузки и выполнять команды в оболочке GRUB.Уязвимость
В функции парольной защиты GRUB было несколько уязвимостей: слабые права доступа к конфигурационному файлу GRUB, позволявшие непривилегированным пользователям получать пароли и/или хэши паролей в открытом виде (например, CVE-2012-2314, CVE-2013-4577 и CVE-2021-3981), целочисленное переполнение (CVE-2015-8370) и даже некорректное сравнение строк (CVE-2009-4128).
Теперь к ним добавилась еще одна уязвимость: CVE-2023-4001.
Уязвимость позволяет непривилегированным пользователям на многих системах с UEFI (но не на всех) обойти проверку пароля, выставленного в GRUB2 для ограничения доступа к загрузочному меню или командной строке загрузчика. В некоторых редких случаях непривилегированный доступ не требуется, достаточно физического доступа без возможности входа в операционную систему.
Уязвимость вызвана изменением, добавленным компанией Red Hat в пакет с GRUB2, поставляемый в RHEL и Fedora Linux. Проблема не проявляется в основном проекте GRUB2 и затрагивает только дистрибутивы, применившие дополнительные патчи Red Hat.
Команды, необходимые для правильного включения функции защиты паролем в менеджере загрузки GRUB, могут храниться в двух местах: в главном конфигурационном файле, встроенном в образ GRUB ("/boot/grub/grub.cfg" или "/boot/grub2/grub.cfg", который является исполняемым файлом EFI), и во "внешнем" конфигурационном файле ("/boot/efi/EFI/<vendor>/grub.cfg").
Но так как в UEFI Secure Boot образы GRUB подписаны, они не могут содержать ничего, кроме жестко закодированного пароля или его хэша. Поэтому соответствующие команды должны храниться "снаружи", тем самым конфигурация загрузчика разделяется между двумя файлами.
Когда пароль GRUB установлен, он записывается в главный файл. А "внешний" - это простой скрипт для нахождения и выполнения главного конфигурационного файла. Если бы команды, связанные с паролем, хранились в "внешнем" файле, то проблемы не было бы.
Если главный файл не найден, то менеджер загрузки GRUB запустит свою оболочку. И здесь заключается весь фокус - мы можем заставить основной конфигурационный файл “исчезнуть” (по крайней мере, в некоторых системах) при выполнении "внешнего" файла. Таким образом, запроса пароля не будет и оболочка GRUB будет немедленно доступна физически присутствующему пользователю.
Как это сделать? Все дело в том, что через внешний накопитель, такой как USB Flash, можно обойти аутентификацию, выставив для него UUID, который повторяет идентификатор загрузочного раздела /boot атакуемой системы. Основной конфигурационный файл находится по предопределенному пути: “<устройство>/grub2/grub.cfg”. Здесь “<устройство>” - это том, найденный по UUID его файловой системы с помощью команды “search”.Пример стандарта UUID
Дублирующиеся UUID файловой системы создают проблему безопасности. Многие UEFI-системы в первую очередь обрабатывают внешние накопители и ставят их в списке обнаруженных устройств перед стационарными накопителями, поэтому более приоритетным при обработке будет раздел /boot, подготовленный атакующим, и, соответственно, из этого раздела GRUB2 попытается загрузить файл конфигурации. В процессе поиска раздела при помощи команды "search" в GRUB2 выполняется определение только первого совпадения UUID, после чего поиск прекращается. Если в определённом разделе основной файл конфигурации не будет найден, GRUB2 выведет приглашение командной строки, позволяющее полностью контролировать дальнейший процесс загрузки.
Для определения UUID раздела локальным непривилегированным пользователем может использоваться утилита "lsblk", но посторонний пользователь, не имеющий доступа к системе, но способный наблюдать процесс загрузки, в некоторых дистрибутивах может определить UUID из показываемых во время загрузки диагностических сообщений.
Уязвимость устранена компанией Red Hat через добавление к команде "search" нового аргумента, позволяющего привязать операцию сканирования UUID только к блочным устройствам, используемым для запуска загрузочного менеджера (т.е. раздел /boot должен быть только на том же диске, что и системный
раздел EFI).От себя
Несмотря на то, что уязвимость устранена, пользователи RHEL и Fedora Linux могут быть восхищены дырками от любимой корпорации. По мне так отличный бекдор. В Red Hat похоже существует соревнование: кто добавит самые дырявые патчи к GRUB. Они, наверное, какую-то одну госпрограмму осваивают: помоги агенту Смиту войти в систему пользователя...
Источник новости: habr.com
