Linux может стартовать с ошибкой: проблемы в загрузчике

В драйвере GRUB2 для работы с NTFS файловой системой обнаружена уязвимость ( CVE-2023-4692 ), которая позволяет выполнять произвольный код на стадии загрузчика при обращении к специально оформленному образу файловой системы. Уязвимость может применяться для обхода механизма верифицированной загрузки UEFI Secure Boot.

Проблема безопасности связана с ошибкой в коде, который анализирует NTFS-атрибут “$ATTRIBUTE_LIST” (grub-core/fs/ntfs.c). Ошибка позволяет записывать данные, которые контролируются пользователем, в память за пределами выделенного буфера. Если загрузчик обрабатывает специально подготовленный образ NTFS, то это может привести к тому, что часть памяти GRUB будет перезаписана, а также, в некоторых случаях, к тому, что будет повреждена память прошивки UEFI. Это потенциально дает возможность запустить свой код на уровне загрузчика или прошивки.

Также в том же NTFS-драйвере GRUB2 найдена другая уязвимость (CVE-2023-4693), которая позволяет читать память при разборе атрибута "$DATA" в специально оформленном образе NTFS. Уязвимость может привести к утечке данных или выявлению значений EFI переменных.

Решение проблемы пока доступно только в форме патча . Статус исправления в различных дистрибутивах можно отследить на сайтах: Debian, Ubuntu, SUSE, RHEL, Fedora. Для полного решения проблемы в GRUB2 требуется не только обновление пакета, но и новые подписи, а также обновление различных компонентов, включая загрузчики, пакеты с ядром, fwupd-прошивки и shim-прослойку.

Во многих Linux-дистрибутивах для верифицированной загрузки с использованием UEFI Secure Boot применяется прослойка shim, заверенная цифровой подписью Microsoft. Эта прослойка проверяет GRUB2 своим сертификатом, освобождая разработчиков от необходимости подписывать каждое обновление ядра и GRUB у Microsoft. Уязвимости в GRUB2 могут позволить выполнить код после проверки shim, но после успешной верификации shim, но до загрузки операционной системы, вклинившись в цепочку доверия при активном режиме Secure Boot и получив полный контроль за дальнейшим процессом загрузки, например, для загрузки другой ОС, модификации компонентов операционной системы и обхода защиты Lockdown.

Для предотвращения эксплуатации уязвимости, не отзывая при этом цифровую подпись, дистрибутивы могут применять систему SBAT (UEFI Secure Boot Advanced Targeting, оддержка которого реализована для GRUB2, shim и fwupd в большинстве популярных дистрибутивов Linux. Механизм SBAT, разработанный в партнерстве с Microsoft, позволяет добавлять дополнительные метаданные в исполняемые файлы компонентов UEFI, содержащие информацию о производителе, продукте и его версии. Указанные метаданные заверяются цифровой подписью и могут отдельно включаться в списки разрешённых или запрещённых компонентов для UEFI Secure Boot.

С помощью SBAT можно блокировать цифровые подписи для конкретных версий компонентов, минуя процесс отзыва ключей Secure Boot. Блокирование уязвимостей через SBAT не требует использования списка отозванных сертификатов UEFI (dbx), а производится на уровне замены внутреннего ключа для формирования подписей и обновления GRUB2, shim и других поставляемых дистрибутивами загрузочных артефактов. До внедрения SBAT, обновление списка отозванных сертификатов (dbx, UEFI Revocation List) было обязательным условием полного блокирования уязвимости, так как атакующий, независимо от используемой операционной системы, мог для компрометации UEFI Secure Boot использовать загрузочный носитель со старой уязвимой версией GRUB2, заверенной цифровой подписью.