Фазы загрузки UEFI и способы контроля исполняемых образов

Фазы загрузки UEFI и способы контроля исполняемых образов

Черчесов А. Э., МФТИ

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

Ключевые слова: UEFI BIOS, DXE Phase, PEI Phase, Boot Firmware Volume (BFV), DXE Core.

UEFI boot stages and ways to control executable images

The article describes the UEFI boot phases, the ways of embedding executable images in various phases, and ways how to protect against malicious code in the UEFI BIOS.

Keywords: UEFI BIOS, DXE Phase, PEI Phase, Boot Firmware Volume (BFV), DXE Core.

Базовая система ввода-вывода (BIOS) давно перестала быть простейшей микропрограммой, главной целью которой является инициализация и тестирование на низком уровне аппаратных компонентов компьютера для дальнейшей передачи управления загрузчику операционной системы (ОС). С момента введения единого расширяемого микропрограммного интерфейса (Unified Extensible Firmware Interface, UEFI) BIOS приобретает черты упрощенной современной операционной системы со своими фазами загрузки и механизмами обеспечения безопасности, включая реализацию различных криптографических функций [1]. UEFI также позволяет расширять прошивку платформы, загружая исполняемые образы – драйверы или приложения. Исполняемые образы представляют собой класс файлов, определенных спецификацией UEFI, которые содержат исполняемый код. Загруженные образы получают доступ к сервисам, которые также определены спецификацией UEFI (boot services, runtime services) [2. С. 31]. Исполняемые образы могут быть загружены в память как встроенным менеджером загрузки, так и другими исполняемыми образами [3. С. 17]. Данная возможность позволяет расширять функционал базовой системы ввода-вывода, однако, она создает новые векторы атак в случае неконтролируемого встраивания драйверов.

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

Внедрение в BIOS дает возможность распространить влияние вредоносного кода на все последующие этапы загрузки. Под угрозой оказываются код управления системой (System Management Mode, SMM), существующие средства защиты, загрузчики, гипервизор и операционная система (ОС). Учитывая, что BIOS запускается с высоким уровнем привилегий на одном из первых этапов загрузки ЭВМ, вредоносный код, исполняемый на уровне BIOS, очень сложно детектировать и устранить на последующих этапах. Для понимания способов инъекций вредоносного кода в UEFI и защиты от них, необходимо ознакомиться со всеми фазами загрузки и возможностями инъекции кода в каждую из них.

Согласно спецификации UEFI система проходит следующие этапы загрузки: Security (Sec), Pre EFI Initialization (PEI), Driver Execution Environment (DXE), Boot Dev Select (BDS) [2. С. 11].

Внедрение в фазу Security невозможно из-за проприетарности данной стадии. В данной фазе подготавливается временная память, адрес и размер которой передаются в фазу PEI. Помимо этого в фазу PEI передается адрес и размер стека, состояние платформы, адрес и размер BFV (Boot Firmware Volume) [4].

В фазе PEI инициализируется RAM для запуска фазы DXE. В фазу DXE передается информация об обнаруженных устройствах для корректной инициализации каждого из устройств. Фаза PEI состоит из ядра и модулей PEIM, осуществляющих первичную инициализацию устройств. Список PEIM может быть расширен путем добавления собственных модулей. Ядро PEI обходит все тома прошивки в поиске всех PEI модулей и запускает их. Порядок запуска модулей не случаен и определяется диспетчером PEI. Модули могут иметь зависимости от других модулей, поэтому сперва запускаются модули, не имеющие зависимостей, затем модули, зависящие от них по цепочке [4].

Код DXE состоит из ядра (DXE Core), диспетчера и драйверов. Ядро инициализирует и запускает службы UEFI. Диспетчер осуществляет поиск всех DXE-драйверов и передачу управления каждому из них. Данные драйверы могут содержать зависимости от других компонентов. Каждый DXE-модуль может осуществлять загрузку и запуск исполняемых образов, одним из которых может выступать загрузчик ОС. После исполнения драйверов осуществляется поиск загрузчика ОС [4].

Таким образом, инъекция драйвера как в фазу PEI, так и в DXE может нарушить процесс загрузки ОС, запустив исполняемый образ в UEFI. Рассмотрим практический способ влияния на процесс загрузки на примере инъекции вредоносного DXE-драйвера с использованием утилиты UEFI Tool и программатора. UEFI Tool позволяет считывать и редактировать бинарный файл прошивки (BFV), расширяя его исполняемым кодом и различными данными. В качестве примера приведем сценарий встраивания и функционирования вредоносного драйвера в одной из фаз.

Стоит отметить, что такой драйвер может иметь как примитивный вид, так и представлять собой многофункциональный программный компонент. Для простоты понимания можно ввести допущение, что загружаемый исполняемый образ расположен в корне одной из файловых систем. Данное допущение не уменьшает значимости данного вектора атаки на BIOS, так как исполняемый образ может быть загружен в систему в режиме выполнения самим драйвером, содержащего вредоносный код. Получив список всех файловых систем, драйвер осуществит проверку наличия необходимого образа и, в случае успеха, загрузит код в память и передаст ему управление. Стоит заметить, что для поиска исполняемого образа в коде драйвера могут использоваться протоколы. Как было сказано выше, порядок получения управления различными драйверами строго не определен, а это значит, что на момент выполнения используемые протоколы могут быть еще не доступны для использования. Для обеспечения доступности используемых протоколов необходимо использовать секцию [Depex]. В данной секции указывается список протоколов, использование которых необходимо разрабатываемому драйверу. Эта секция обеспечит получение драйвером управления только тогда, когда системные службы или другие драйверы предоставят доступ к использованию необходимых протоколов, указанных в этой секции.

Считав программатором с чипа бинарный файл прошивки, злоумышленник может приступить к ее модификации. Полученные после сборки исходного кода драйвера файлы необходимо обернуть в определенный формат и добавить в один из томов прошивки системы. Злоумышленник успешно завершит атаку, записав программатором модифицированный бинарный файл на чип обратно.

Рассмотренный способ влияния на процесс загрузки подтверждает необходимость проверки каждого из DXE-драйверов, получающих управление, так как каждый из них может содержать потенциально вредоносный код. Доверенную загрузку можно нарушить не только инъекцией DXE-драйверов, но и PEI-драйверов. Разработка драйверов PEI (как для вирусов, так и для средств защиты) сложнее, так как недоступна проинициализированная память, протоколы и системные службы. Однако, процедура инъекции PEI-драйвера в один из томов прошивки системы ничем не отличается.

Для обеспечения защиты от неконтролируемого встраивания драйверов программными средствами необходимо обеспечить гарантированное получение управления средствами защиты при каждом старте ЭВМ до запуска модулей PEI и DXE и невозможность осуществить загрузку ОС в обход средств защиты.

Гарантированное получение управления до запуска модулей можно обеспечить только в случае функционирования средства защиты на уровне PEI Core или SEC. Учитывая проприетарность кода фазы SEC, внедрение компонента защиты в PEI Core представляется правильным. Невозможность осуществить загрузку ОС в обход средств защиты можно обеспечить исключительно путем сертификации BIOS и опломбирования корпуса ЭВМ. Однако, имея сертифицированный BIOS и опломбированный корпус, можно смело утверждать, что компонент безопасности, реализованный в виде DXE-драйвера, получит управление и не позволит нарушить доверенную загрузку, проведя процедуру аутентификации и контроля целостности.

Средство защиты, которое обеспечит проверку драйверов, может быть не только программным, но и программно-аппаратным. Программная составляющая такого средства может также представлять собой DXE-драйвер, который в сочетании с аппаратно-реализованным сторожевым таймером не позволит вредоносному коду продолжить процесс загрузки в обход средства защиты. В случае, если драйвер средства защиты не получит управление через определенное время после старта системы, сторожевой таймер выполнит перезапуск системы аппаратными способами.

Итак, удалось убедиться, что вполне доступными средствами можно осуществить инъекцию вредоносного кода путем расширения BFV DXE-драйвером, более того, это было проделано на практике в стендовых условиях. В то же время эта угроза может быть сведена к нулю, если системную прошивку BIOS UEFI расширить средством защиты, которое будет перехватывать управление при старте, проводить аутентификацию и проверку целостности и в случае успеха продолжать процедуру загрузки.

Список литературы

1. Лыдин C. О средствах доверенной загрузки для аппаратных платформ, реализующих спецификацию UEFI // Научно-практический журнал/ФГУП «ВИМИ», М., 2016. Вып. 3. № 114. С. 45–50. URL: http://www.okbsapr.ru/lydin_2016_1.html (дата обращения: 15.05.2017).
2. Zimmer V., Rothman M., Marisetty S. Beyond BIOS Second Edition, Intel Press, ноябрь 2010 г. URL: https://www.microbe.cz/docs/Beyond_BIOS_Second_Edition_Digital_Edition_(15-12-10)%20.pdf (дата обращения: 15.05.2017).
3. Unified Extensible Firmware Interface Specification Version 2.6 Январь, 2016 г. URL: http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf (дата обращения: 15.05.2017).
4. Agneessens J.-F. Analysis of the building blocks and attack vectors associated with the Unified Extensible Firmware Interface (UEFI) (SANS Institute InfoSec Reading Room). URL: https://www.sans.org/reading-room/whitepapers/services/analysis-building-blocks-attack-vectors-unified-extensible-firmware-34215 (дата обращения: 20.03.2018).

Автор: Черчесов А. Э.

Дата публикации: 01.01.2018

Библиографическая ссылка: Черчесов А. Э. Фазы загрузки UEFI и способы контроля исполняемых образов // Вопросы защиты информации. М., 2018. № 2 (121). С. 51–53.

---