Доверенная загрузка GNU-Linux в режиме UEFI Secure Boot в 2021 году (Николай Костригин, OSSDEVCONF-2021) — различия между версиями

…|}}
|10NmfaMrVfo}}
{{SlidesSection}}
[[File:Доверенная загрузка GNU-Linux в режиме UEFI Secure Boot в 2021 году (Николай Костригин, OSSDEVCONF-2021).pdf|left|page=-|300px]]

{{----}}

== Thesis ==

Текущая версия на 23:00, 18 мая 2022

Докладчик

Николай Костригин

В докладе рассматривается технология доверенной загрузки на базе UEFI Secure Boot и реализация поддержки этой технологии в дистрибутивах GNU/Linux.

Даётся историческая ретроспектива организации подписи stage1 загрузчика shim и обзор текущего состояния дел в этой сфере.

Приводятся требования к инфраструктуре подписи исполняемых файлов на примере репозиториев компании Базальт СПО.

Обсуждаются тенденции ужесточения режима Secure Boot и их возможное влияние на мир СПО.

Видео

on youtube

Презентация

Thesis

Введение

EFI, а позднее UEFI является спецификацией описывающей расширяемый интерфейс загрузочной прошивки вычислительной машины, пришедшей на смену BIOS.

Позиция EFI в стеке компонентов вычислительной системы.

Причиной для выполнения подобной работы явились ограничения BIOS унаследованные ей от первых IBM PC: выполнение в 16-битном реальном режиме процессора, вытекающее из этого ограничение на объём используемой оперативной памяти и другие.

На данный момент UEFI поддерживается несколькими аппаратными платформами, в частности ix86 (ia32, x64), ARM/ARM64 (aarch32, aarch64), RISCV32/RISCV64, существует реализация для MIPS.

UEFI Secure Boot

Протокол Secure Boot (защищённая загрузка, далее «SB») стал опциональной частью спецификации UEFI. Он основан на ассиметричной криптографии и позволяет построить цепочку доверия от аппаратной платформы до запуска ядра операционной системы. Причиной для его появления называлась защита от выполнения недоверенного кода на всех этапах загрузки системы и попытка защититься от внедрения UEFI Boot kit, вредоносного ПО способного записать себя в энергонезависимую память и скомпрометировать загружаемую ОС.

Shim: stage1 загрузчик c поддержкой Secure Boot

Для решения проблемы запуска ОС на базе GNU/Linux было разработано минимум два загрузчика, которые в Microsoft согласились подписать — это PreLoader.efi от Linux Foundation, не получивший, однако, широкого распространения, и shim от RedHat и SUSE.

Shim распространяется под лицензией BSD-3-Clause и является компромиссом между необходимостью иметь подписанный загрузчик для режима SB у сообщества свободного ПО и нежеланием Microsoft подписывать, например grub2, распространяемый под лицензией GPLv3. [1]

Во многих реализациях UEFI-прошивок пока сохраняется возможность очистить заводскую базу доверенных сертификатов, заменив своими, или дополнить её.

Для полноценной поддержки доверенной загрузки в дистрибутиве GNU/Linux подписаны должны быть, как минимум, все стадии загрузчиков и ядро операционной системы. Для возможности запуска shim в режиме SB он должен быть подписан ключом Microsoft. Остальные стадии загрузки могут быть заверены самоподписным сертификатом поставщика ПО.

Shim-review и подпись файлов shim в Microsoft

Процедура подписи shim претерпела ряд изменений за прошедшие годы.

В 2012-13 годах процедура заключалась, по сути, в отсылке подписанного ключом разработчика *.cab-архива содержащего неподписанный shim.efi и получении zip-архива с подписанным файлом. Этот процесс, хорошо задокументирован в статье Михаила Шигорина [2].

В конце 2017 появилась дополнительная процедура проверки исходного кода загрузчиков, получившая название shim-review. В состав комитета, осуществляющего ревью кода вошли представители Debian, RedHat, SUSE, Ubuntu. Результаты проверки хранятся в соответствующем репозитории на GitHub [3].

Для доказательства соответствия представленных на подпись бинарных файлов shim исходному коду выполняется их тестовая пересборка, сравнение sha256 хэшей.

Для удостоверения организации и подписи отправляемых ей в Microsoft файлов она должна заказать EV (Extended Validation) Code Sign сертификат у одного из крупных центров авторизации (CA), что возможно только при наличии сведений о компании в одном из международных бизнес-справочников.

Уязвимости цепи доверенной загрузки и обновлённые требования процедуры shim-review

В 2020 году был обнародован набор уязвимостей в загрузчике grub2, позволявших обойти активированный Secure Boot и выполнить произвольный код загрузки на уязвимой машине. Он получил название «Boot Hole». Исправление всего списка CVE включало набор из 28 патчей. Этот инцидент привлёк внимание большого количества исследователей безопасности. В результате, спустя несколько месяцев, был обнародован ещё один набор уязвимостей, который стали называть Secure Boot Bypass 2021. Исправление для него включало уже 123 патча.

Чтобы исключить возможность загрузки ранее подписанных уязвимых версий grub2 необходимо внести изменения во всю цепочку доверия дистрибутива.

Масштаб проблемы связанный с двумя упомянутыми инцидентами вскрыл проблему в дизайне UEFI: для отзыва всех подписанных копий загрузчиков потребовалось бы занять порядка половины объёма NVRAM отведённого под чёрный список DBX. В экстренном порядке был разработан улучшенный механизм отзыва недоверенных EFI-программ, который получил название SBAT — Secure Boot Advanced Targeting.

Пример исходных данных для генерации .sbat секции для доверенных EFI программ.

По сути SBAT представляет собой дополнительную ELF-секцию (.sbat) добавляемую к каждому доверенному EFI-загрузчику или EFI-программе и содержащую информацию о происхождении (версии апстримного кода), вендоре и поколении (версии релиза от момента внедрения SBAT вендорами) этого загрузчика (Рис. 2). В случае обнаружения уязвимости в одном из загрузчиков отзыв может быть осуществлён более адресно, без нерационального расходования ресурса NVRAM. Подробнее о SBAT можно прочитать в [4].

Итак, ключевыми отличиями обновлённой процедуры shim-review в 2021 году являются :

1. требование наличия .sbat секции в бинарных файлах;
2. требование замены встроенного сертификата или добавление всех ранее подписанных уязвимых бинарных файлов в чёрный список;
3. запрет подписи новым сертификатом старых (не содержащих исправления для Boot Hole + SB Bypass 2021) сборок grub;
4. ограничение списка по-умолчанию доверенных загрузчиков (фактически до связки shim->grub2->vmlinuz)
5. требование использования HSM для хранения ключей и сертификатов подписи.

Почему все дороги ведут в Microsoft?

Сертификаты, попадающие в UEFI firmware большинства IBM-PC совместимых машин, доступных на современном рынке, включают таковые от производителя конкретного аппаратного решения и от корпорации Microsoft, как поставщика наиболее часто предустанавливаемой ОС. Поставщиков компьютеров много, а поставщик ОС Windows — один. Это привело к ситуации, в которой общим сертификатом для большинства машин с поддержкой UEFI SB является именно сертификат Microsoft и корпорация оказалась в положении центрового игрока на поле доверенной загрузки PC-совместимых компьютеров. От решения её экспертов зависит сможет ли тот или иной программный продукт загружаться без отключения режима Secure Boot.

Список доверенных сертификатов в разделе Authorized Keys UEFI одной из серийных PC-совместимых машин предустановленных при производстве.

Справедливости ради, хотелось бы отметить, что общение как с представителями комитета shim-review, так и с представителями лаборатории Hardware Development Center Microsoft проходит исключительно в конструктивной и доброжелательной манере.

Требования к инфраструктуре сборочных серверов и репозитория

Для подписи бинарных файлов на сборочном сервере репозитория Sisyphus и его стабильных ветвей используется программа pesign. Инструмент создан RedHat и довольно широко распространён среди разработчиков дистрибутивов, развивается ими.

От инструмента получила своё название и группа разработчиков на сборочном сервере ALT Linux Team имеющих право подписывать загрузчики и ядро. Подзадания с такими бинарниками должны получить подтверждение (approve) от члена группы @pesign (Рис. 3). Невыполнение этого правила приведёт к тому, что загрузка машины с активированной опцией Secure Boot после обновления до версии пакета с неподписанным файлом будет нарушена.

Схема организации подписи бинарных файлов в инфраструктуре Базальт СПО.

Проблемы в реализациях UEFI прошивок

Нерешённой проблемой является то, что несмотря на открытость кода UEFI (Tianocore / edk2), исходные коды финальных проприетарных прошивок компьютеров реализующие эту спецификацию остаются закрытыми. При этом поведение кода прошивок тестируется, как правило, только на совместимость с MS Windows, а совместимость с другими ОС не просто не тестируется, но иногда даже открыто игнорируется.

Примером такой реакции может служить недавний отказ техподдержки Acer устранить проблемы в коде автоматического создания и выбора загрузочной записи в прошивке ноутбука Acer Swift 3. В процессе исследования проблем с загрузкой ноутбука была выявлена, на наш взгляд, серьёзная проблема: при составлении и отображении списка загрузки вместо текста из полей создаваемых в NVRAM в элементы списка попадает текст из случайных областей памяти. Рис. 5 иллюстрирует, как вместо опции загрузки отображается набор символов повторяющий имя производителя прошивки из заголовка окна. Исправления этой ошибки нет в течение более, чем 3 месяцев.

Иллюстрация чтения произвольных областей памяти в UEFI прошивке ноутбука Acer Swift 3.

Также начинает прослеживаться тенденция невозможности отключения Secure Boot или замены доверенных сертификатов на пользовательские в ряде моделей потребительских устройств выпускаемых в последнее время.

В некоторых прошивках заявленный функционал CSM реализован с приоритетом UEFI. Это приводит к тому, что в гибридных образах загрузчиков инсталлятора (на примере линейки ОС Альт) активация режима CSM (Legacy BIOS) всё равно приводит к старту машины в режиме UEFI и запуску соответствующего инсталлятора, если обнаружена загрузочная партиция EFI.

UEFI SB по ГОСТу

Существующая спецификация UEFI (самая свежая версия 2.9 от марта 2021 года) не содержит поддержки криптографии по ГОСТ (только DSA и RSA).

Однако, в число организаций, участвующих в UEFI Forum от России, входят ИСП РАН и Kraftway. Возможно они могли бы стать пионерами применения криптографии по ГОСТ, сначала в локальных версиях прошивок, а затем и предложив эти изменения в апстримный код.

Также для отечественных систем с локализованной версией UEFI разумно было бы встраивать ключи российских производителей и центра сертификации наряду с иностранными.

Заключение

Подводя итог всему сказанному, нужно отметить, что UEFI Secure Boot и её поддержка в ОС на базе GNU/Linux становится всё более зрелой, обнаруживаются и исправляются ошибки. Однако, наряду с этим, текущая реализация прошивок UEFI страдает от отсутствия диверсификации удостоверяющих центров, в том числе российских, а также закрытости исходных текстов проприетарных прошивок, что ограничивает доверие к ним.

Примечания и ссылки

• Discuss on VK
• Discuss on Facebook

• https://github.com/rhboot/shim-review/issues/165

Plays:4   Comments:0