Уязвимость в NTFS-драйвере из состава GRUB2, позволяющая выполнить код и обойти UEFI Secure Boot

В драйвере, обеспечивающем работу с файловой системой NTFS в загрузчике GRUB2, выявлена уязвимость (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, но до загрузки операционной системы, вклинившись в цепочку доверия при активном режиме 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 использовать загрузочный

Источник: opennet.ru