Подготовка инструментов под фаззинг UEFI на базе edk2 в Windows

Так повелось в мире, что время от времени необходимо проводить исследования безопасности драйверов и прошивок. Одним из способов исследования является - фаззинг (Fuzzing). Не будем останавливаться на описание на самого процесса фаззинга, для этого есть эта статья, отметим только, что в основном его используют для исследования прикладных приложений. И тут возникает вопрос: как профаззить прошивку, в частности прошивку UEFI? Здесь будет рассказано об одном из способов с использованием программного эмулятора EDKII, чтобы проводить фаззинг без развертывания аппаратных стендов. И что важно, все это сделаем в Windows.

Сразу, что такое EDKII? - это среда разработки и эмулятор ПО согласно спецификации UEFI. Про разработку в EDKII есть ряд статей (вот и вот), а наша задача связать эмулятор EDKII и фаззер.

А реализовывать инструментацию будем под фаззер WinAFL.

Стартуем!

Как это сделать? Вот несколько решений раз, два, три и четыре.

Решение Раз

Первое решение - найти что-нибудь готовое - это HBFA.

HBFA - анализатор ПО из экспериментального набора edk2-staging, в Windows работает в связке с DynamoRio - динамическим инструментатором кода. В ходе исследования было выяснено, что если в прошивке есть код, завязанный на определенную сборочную систему с специальными библиотеками, то данное решение, без серьезной переработки готового кода, не встраивается. Тогда переходим к решению два.

Решение Два

Решение два - это внедрение в код систему Intel® ITS ( Intel® Intelligent Test System) для инструментации. Система используется для определения меры покрытия кода.

В результате выполнения инструментированного кода Intel® ITS создается файл exec. Для того, что бы связать выполнение такого кода с фаззером и оценить количество путей, надо производить подсчет контрольной суммы от файла exec и записи его в карту AFL.

           HANDLE mem = OpenFileMapping(FILE_MAP_ALL_ACCESS, false, shm);
           areaPtr = MapViewOfFile(mem, FILE_MAP_ALL_ACCESS, 0, 0, 0);
           if(areaPtr == NULL){
              out << "shm value failed" << std::endl;
              out.close();
           }
           __afl_area_ptr = (char*)areaPtr; 

Решение простое, но дает не честный и не совсем правильный отчет о покрытие кода, поэтому переходим к следующему решению.

Решение Три

Это написание собственного драйвера AFL в UEFI.

Цель драйвера - прокинуть вызовы функций Windows в эмулятор EDKII. Для этого необходимо выполнить следующие действия:

1. Реализовать драйвер уровня DXE;

2. Реализовать функции драйвера на уровне выполнения Windows;

3. Зарегистрировать драйвер в эмуляторе;

4. Реализовать протокол драйвера в прошивке.

DXE драйвер

На платформе эмулятора EmulatorPkg определен протокол EMU_IO_THUNK_PROTOCOL. Протокол EMU_IO_THUNK_PROTOCOL используется для абстрагирования зависимых от ОС операция ввода-вывода для других протоколов UEFI, например: GOP, SimpleFileSystem и так далее. Одним из таких будет и драйвер для взаимодействия с AFL. Драйвер DXE для AFL будет является экземпляром протокола EFI_BLOCK_IO_PROTOCOL.

EFI_BLOCK_IO_PROTOCOL - протокол для реализации контроллера, протокол EMU также является его реализацией.

Таким образом драйвер DXE для AFL делится на зависящую от ОС реализацию протокола EMU_IO_THUNK_PROTOCOL и независимую часть, для реализации драйвера на уровне UEFI EFI_BLOCK_IO_PROTOCOL.

Перейдем к созданию заголовочного файла драйвера уровня EMU $(workspace)\EmulatorPkg\EmuAflProxyDxe\EmuAflProxy.h.

Здесь указывается структура EMU_AFL_PROXY_PRIVATE:

extern EFI_DRIVER_BINDING_PROTOCOL   gEmuAflProxyDriverBinding;
extern EFI_COMPONENT_NAME_PROTOCOL   gEmuAflProxyComponentName;
extern EFI_COMPONENT_NAME2_PROTOCOL  gEmuAflProxyComponentName2;

#define EMU_AFL_PROXY_PRIVATE_SIGNATURE  SIGNATURE_32 ('E', 'A', 'F', 'l')

typedef struct {
    UINTN                               Signature;
    EMU_IO_THUNK_PROTOCOL               *IoThunk;
    EFI_AFL_PROXY_PROTOCOL              AflProxy;
    EFI_AFL_PROXY_PROTOCOL              *Io;
    EFI_UNICODE_STRING_TABLE            *ControllerNameTable;
} EMU_AFL_PROXY_PRIVATE;

#define EMU_AFL_PROXY_PRIVATE_DATA_FROM_THIS(a) \
  CR (a, \
      EMU_AFL_PROXY_PRIVATE, \
      AflProxy, \
      EMU_AFL_PROXY_PRIVATE_SIGNATURE \
      )

В этой структуре содержатся следующие поля:

• EFI_UNICODE_STRING_TABLE - структура содержащая локализацию и имя драйвера;

• EMU_IO_THUNK_PROTOCOL - протокол использующийся для абстрагирования зависимых от ОС операций ввода-вывода для других протоколов UEFI;

• EFI_AFL_PROXY_PROTOCOL - протокол реализации нашего драйвера UEFI;

• UINTN Signature - идентификатор драйвера.

Ниже представлена инициализация полей этой структуры:

    Private->Signature = EMU_AFL_PROXY_PRIVATE_SIGNATURE;
    Private->IoThunk = EmuIoThunk;
    Private->Io = EmuIoThunk->Interface;

    Private->AflProxy.afl_maybe_log = EmuAflMaybeLog;

    Private->ControllerNameTable = NULL;

• IoThunk - указатель на протокол EMU_IO_THUNK_PROTOCOL;

• Private->Io - указатель к требуемой функции, где будет вызвана Private->Io->afl_maybe_log - определяется путем получения указателя на самого себя;

• Private->AflProxy - указывает, что при обращении к интерфейсу драйвера, будет вызвана EmuAflMaybeLog.

Теперь определим саму функцию EmuAflMaybeLog в файле $(workspace)\EmulatorPkg\EmuAflProxyDxe\EmuAflProxy.c

EFI_STATUS
EFIAPI
EmuAflMaybeLog(
    IN EFI_AFL_PROXY_PROTOCOL   *This,
    IN UINT32                   date
);

Private = EMU_AFL_PROXY_PRIVATE_DATA_FROM_THIS(This);

Status = Private->Io->afl_maybe_log(Private->Io, date);

Когда создаем драйвер, надо определить функции его создания и удаления. Эти функции определенны в структуре EFI_DRIVER_BINDING_PROTOCOL. Ниже указаны прототипы функций, которыми будет эта структура будет проинициализирована:

• EmuAflProxyDriverBindingSupported;

• EmuAflProxyDriverBindingStart;

• EmuAflProxyDriverBindingStop.

EFI_STATUS
EFIAPI
EmuAflProxyDriverBindingSupported(
    IN  EFI_DRIVER_BINDING_PROTOCOL* This,
    IN  EFI_HANDLE                   ControllerHandle,
    IN  EFI_DEVICE_PATH_PROTOCOL* RemainingDevicePath
);

EFI_STATUS
EFIAPI
EmuAflProxyDriverBindingStart(
    IN  EFI_DRIVER_BINDING_PROTOCOL* This,
    IN  EFI_HANDLE                   ControllerHandle,
    IN  EFI_DEVICE_PATH_PROTOCOL* RemainingDevicePath
);

EFI_STATUS
EFIAPI
EmuAflProxyDriverBindingStop(
    IN  EFI_DRIVER_BINDING_PROTOCOL     *This,
    IN  EFI_HANDLE                      ControllerHandle,
    IN  UINTN                           NumberOfChildren,
    IN  EFI_HANDLE                      *ChildHandleBuffer
);

Определим структуру EFI_DRIVER_BINDING_PROTOCOL с указанием функций инициализации драйвера:

EFI_DRIVER_BINDING_PROTOCOL  gEmuAflProxyDriverBinding = {
  EmuAflProxyDriverBindingSupported,
  EmuAflProxyDriverBindingStart,
  EmuAflProxyDriverBindingStop,
  0xa,
  NULL,
  NULL
};

В спецификации EFIAPI определена функция EfiLibInstallDriverBindingComponentName2 которая отвечает за регистрацию имени драйвера, ее надо вызвать при начальной инициализации драйвера. Сделаем это в функции InitializeEmuAflProxy- она будет точкой входа в драйвер.

EFI_STATUS
EFIAPI
InitializeEmuAflProxy(
    IN EFI_HANDLE        ImageHandle,
    IN EFI_SYSTEM_TABLE* SystemTable
)
{
    EFI_STATUS  Status;

    Status = EfiLibInstallDriverBindingComponentName2(
        ImageHandle,
        SystemTable,
        &gEmuAflProxyDriverBinding,
        ImageHandle,
        &gEmuAflProxyComponentName,
        &gEmuAflProxyComponentName2
    );
    ASSERT_EFI_ERROR(Status);

    return Status;
}

В спецификации драйвера указывается точка входа. В файле $(workspace)\EmulatorPkg\EmuAflProxyDxe\EmuAflProxyDxe.inf указываем эту функцию:

[Defines]
  INF_VERSION                    = 0x00010005
  BASE_NAME                      = EmuAflProxy
  FILE_GUID                      = 537B2273-9362-FCA4-7A3F-41949F0E4EDB
  MODULE_TYPE                    = UEFI_DRIVER
  VERSION_STRING                 = 1.0

  ENTRY_POINT                    = InitializeEmuAflProxy

Вызов функций Windows

Реализацию функций зависимых от ОС делаем в файле $(workspace)\EmulatorPkg\Win\Host\WinAflProxy.c

#define WIN_AFL_PROXY_PRIVATE_SIGNATURE SIGNATURE_32 ('A', 'F', 'L', 'P')

typedef struct {
    UINTN                           Signature;
    EMU_IO_THUNK_PROTOCOL*          Thunk;
    EFI_AFL_PROXY_PROTOCOL          AflProxy;
} WIN_AFL_PROXY_PRIVATE;

#define WIN_AFL_PROXY_PRIVATE_DATA_FROM_THIS(a) \
  CR (a, \
      WIN_AFL_PROXY_PRIVATE, \
      AflProxy, \
      WIN_AFL_PROXY_PRIVATE_SIGNATURE \
      )

extern EFI_AFL_PROXY_PROTOCOL gWinAflProxyProtocol;

Здесь определяем структуру EMU_IO_THUNK_PROTOCOL для драйвера с именем mWinAflProxyThunkIo. Она будет использоваться для регистрации драйвера в эмуляторе:

EFI_STATUS
WinAflMaybeLog(
    IN EFI_AFL_PROXY_PROTOCOL   *This,
    IN UINT32               date
);

EFI_STATUS
WinAflProxyThunkOpen(
    IN  EMU_IO_THUNK_PROTOCOL* This
);

EFI_STATUS
WinAflProxyThunkClose(
    IN  EMU_IO_THUNK_PROTOCOL* This
);

EFI_AFL_PROXY_PROTOCOL gWinAflProxyProtocol = {
    WinAflMaybeLog
};


EMU_IO_THUNK_PROTOCOL mWinAflProxyThunkIo = {       
    &gEfiAflProxyProtocolGuid,				        
    NULL,											
    NULL,											
    0,												
    WinAflProxyThunkOpen,							
    WinAflProxyThunkClose,						
    NULL
};

В этой структуре устанавливаются функции управления драйвером, такие как функция открытия драйвера WinAflProxyThunkOpen и его закрытия WinAflProxyThunkClose. Так же в функции WinAflProxyThunkOpen прописывается вызов функции WinAflMaybeLog, в которой уже производится непосредственный вызов функций Windows:

CopyMem(&Private->AflProxy, &gWinAflProxyProtocol, sizeof(Private->AflProxy)); 

Ниже код функции WinAflProxyThunkOpen:

    WIN_AFL_PROXY_PRIVATE* Private;

    Private = AllocateZeroPool(sizeof(*Private));
    if (Private == NULL) {
        return EFI_OUT_OF_RESOURCES;
    }
    Private->Signature = WIN_AFL_PROXY_PRIVATE_SIGNATURE;
    Private->Thunk = This;
    CopyMem(&Private->AflProxy, &gWinAflProxyProtocol, sizeof(Private->AflProxy));
    This->Interface = &Private->AflProxy;

По итогу, стек вызовов при инициализации драйвера будет выглядеть так:

EmuAflProxyDriverBindingStart -> Status = EmuIoThunk->Open(EmuIoThunk); -> WinAflProxyThunkOpen;

Регистрация драйвера

Драйвер регистрируем на уровне выполнения кода зависимого от Windows, для этого в файле $(workspace)\WinAflProxy2\EmulatorPkg\Win\Host\WinHost.h объявляем структуру mWinAflProxyThunkIo описанную выше:

extern EMU_IO_THUNK_PROTOCOL  mWinAflProxyThunkIo;

а в файле $(workspace)\WinAflProxy2\EmulatorPkg\Win\Host\WinHost.c добавляем ее в эмулятор:

AddThunkProtocol (&mWinAflProxyThunkIo, (CHAR16*)PcdGetPtr(PcdEmuAflProxy), TRUE);

В файле $(workspace)\WinAflProxy2\EmulatorPkg\Win\Host\WinHost.inf указываем GUID драйвера, по нему, при старте EmulatorPkg, драйвер будет добавляться в контекст эмулятора:

[Protocols]
  gEfiAflProxyProtocolGuid

Завершаем регистрацию добавлением драйвера в список драйверов прошивки. Это список драйверов загружаемых на DXE стадии, который находится в файлах:

1. $(workspace)\EmulatorPkg\EmulatorPkg.fdf

  ##
  #  DXE Phase modules
  ##
      EmulatorPkg/EmuAflProxyDxe/EmuAflProxyDxe.inf

2. $(workspace)\EmulatorPkg\EmulatorPkg.dsc

  #
  # UEFI & PI
  #
      UefiAflProxy|MdePkg/Library/UefiAflProxy/UefiAflProxy.inf

Официальная документация на эти файлы.

Регистрация интерфейса

Здесь создается интерфейс AflProxy драйвера, не зависимого от ОС. Любой другой модуль UEFI будет обращаться к драйверу через этот интерфейс.

В $(workspace)\MdePkg\Include\Protocol\AflProxy.h объявляем глобальный идентификатор GUID драйвера EFI:

extern EFI_GUID gEfiAflProxyProtocolGuid;

И прототип функции afl_maybe_log, которая является основной функцией в драйвере:

typedef 
EFI_STATUS
(EFIAPI* EFI_AFL_MAYBE_LOG) (
    IN EFI_AFL_PROXY_PROTOCOL* This,
    IN UINT32 date
    );

struct _EFI_AFL_PROXY_PROTOCOL {
    EFI_AFL_MAYBE_LOG afl_maybe_log;
};

Также создаем библиотеку для обращения к интерфейсу AflProxy для упрощения вызова его функций. В ее составе будет два файла:

Заголовочный файл, где прописан прототип: $(workspace)\MdePkg\Include\Library\UefiAflProxy.h

EFI_STATUS afl_log2( IN UINT32 data);

и ее непосредственная реализация $(workspace)\MdePkg\Library\UefiAflProxy\UefiAflProxy.c:

EFI_STATUS afl_log2( IN UINT32 data) {
    EFI_STATUS Status = 0;

    EFI_AFL_PROXY_PROTOCOL* AflProxy;
    Status = gBS->LocateProtocol(
        &gEfiAflProxyProtocolGuid,
        NULL,
        (VOID**)&AflProxy
    );

    if (EFI_ERROR(Status)) {
        return Status;
    }
    AflProxy->afl_maybe_log(AflProxy, data);
    return Status;
}

Отметим, что код

    Status = gBS->LocateProtocol(
        &gEfiAflProxyProtocolGuid,
        NULL,
        (VOID**)&AflProxy
    );

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

Тестируем

Добавляем вызов afl_log2, с аргументом 200, в приложение HelloWorld.efi и пересобираем эмулятор.

EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  UINT32  Index;
  afl_log2(200);
  Index = 0;
...

Сборка прошла успешно,

запускаем WinHost.exe, и вызываем приложение HelloWorld.efi:

Запуск прошел успешно. Также видно, что в cmd отображено число 200, что значит что драйвер успешно вызвал функции Windows в контексте EFI:

Решение Четыре

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

Заметим, что концептуальная схема запуска любого драйвера, в среде эмулятора, такая:

WinHost.exe -> driver.efi -> driver.dll

Запустив procmon убеждаемся, что вызов драйвера в эмуляторе производится в едином контексте

Убедившись в этом, начинаем писать свою Dll - создаем ее заголовочный файл:

Inject.h

#pragma once

#define IMPORT __declspec(dllimport)
#define EXPORT extern "C" __declspec(dllexport)

EXPORT void WinAflProxyDll(int point);

В этом файле обозначена только одна экспортируемая функция WinAflProxyDll , именно она будет вызываться в эмуляторе. Обратим внимание на эту строку extern "C" __declspec(dllexport) - она необходима, что бы не было конфликта имена при импорте функции в эмулятор.

Файл Inject.cpp

В этом файле содержится реализация экспортируемой функции:

EXPORT void WinAflProxyDll(int point)

По сути, ее код ничем не отличается от того кода, который описан здесь. Просто поподробней пройдемся по ее содержимому.

Обмен данными, между исследуемым приложением и winafl осуществляется при помощи разделяемой памяти shared memory, а адрес этой памяти передается между процессами через переменную среды AFL_STATIC_CONFIG. В приложении, значение переменной среды получаем функцией GetEnvironmentVariable :

GetEnvironmentVariable(TEXT("AFL_STATIC_CONFIG"), envbuff, env_size);

Само это значение имеет следующий вид: id_mem : counter_loop , где counter_loop отвечает за количество запусков при использовании __afl_persistent_loop(), а id_mem это сам идентификатор разделяемой памяти. Пример: 5e0ff10ec40c0919:1000.

Код ниже уже непосредственно отвечает за открытие разделяемой памяти и получения на нее указателя:

HANDLE mem = OpenFileMapping(FILE_MAP_ALL_ACCESS, FALSE, shm);

areaPtr = MapViewOfFile(mem, FILE_MAP_ALL_ACCESS, 0, 0, 0);

Файл Source.def

Создаем файл DEF для описания атрибутов Dll:

LIBRARY "Edk2WinAflDll"
EXPORTS WinAflProxyDll

Добавление Dll в эмулятор

К сожалению, без внедрения кода в эмулятор руками обойтись не удалось, но получилось в разы его уменьшить

В файл winhost.c добавляем импорт функции из Dll:

#pragma once

#define IMPORT __declspec(dllimport)
#define EXPORT extern "C" __declspec(dllexport)

IMPORT void WinAflProxyDll(int point);

В контексте работы эмулятора выделим адрес 0x10000000, по нему будет записан указатель на эту функцию:

#define addr 0x10000000

typedef struct Variable {
  void (*var)(int);
}Variable;

Выделение памяти и запись по данному адресу указателя на функцию WinAflProxyDll делается для того, что бы в любом контексте выполнения эмулятора, был доступ к функции из Dll:

VirtualAlloc((void*)addr, sizeof(Variable), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
  ((Variable*)addr)->var = (void(*)(int))(WinAflProxyDll);
  callAflProxyDll(7);

Получать же динамически адрес с использованием import Table не получится, так как функции winapi, из контекста драйвера DXE, недоступны.

Вызов функции из произвольного места будет производится функцией callAflProxyDll:

#ifndef _INJECT_EDK_H_
#define _INJECT_EDK_H_

#define addrInject 0x10000000
inline void callAflProxyDll(int point) {
  void(*f_ptr)(int);
  f_ptr = *((void(**)(int))(addrInject));
  f_ptr(point);
}
#endif

 __asm {
    push point
    mov eax, addr
    call[eax]
    add  esp, 4
  }

Надо еще добавить Dll в конфигурационный файл эмулятора, для этого в файл $(workspace)\EmulatorPkg\Win\Host\WinHost.inf добавляем путь до Dll:

[BuildOptions]
    MSFT:*_VS2017_IA32_DLINK_FLAGS     = /LIBPATH:"%VCToolsInstallDir%lib\x86" 
    ... 
    Advapi32.lib \Edk2WinAflDll.lib

Инструментация

Что такое инструментация кода? Это процесс внедрения исполняемых инструкций в уже готовый код. Инструментация бывает статическая и динамическая.

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

Учитывая, что запуск эмулятора EDK высокозатратная операция, будем использовать статическую инструментацию.

Стандартная статическая инструментация afl производится при сборке, путем вставки ассемблерных инструкций в промежуточный код gcc.

Для MSBuild идем тем же путем, находим опцию генерации промежуточного ассемблерного кода /FA иии... фиаско. Узнаем, что промежуточный ассемблерный код не является исполняемым, а существует только для демонстрации.

Тогда вооружившись стандартом С++11 начинаем писать свой парсер-инструментатор кода Си.

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

1. Работа препроцессора;

2. Построение AST-дерева;

3. Инструментация.

Имея инструментатор, его надо встроить в процесс сборки, для этого меняем файл conf\build_rule :

[C-Code-File]
  <Command.MSFT, Command.INTEL>
        "$(CC)" /Fo${dst} $(DEPS_FLAGS) $(CC_FLAGS) $(INC) ${src}
        #python your parser "$(CC)" /Fo${dst} $(DEPS_FLAGS) $(CC_FLAGS) $(INC) ${src}

Сюда добавляется вызов инструментатора.

Выводы?

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

Готовый инструментатор на основе внедрения инструкций в код не стабилен и в будущем от него надо уйти.

Спасибо!

PS. ссылки на готовый код ниже:

1. Инструментатор https://github.com/yrime/Edk2InstrV2;

2. DXE драйвер;

3. HBFA;

4. Dll Afl.