SmmExploit

Este es un informe y un exploit de CVE-2021-26943, la vulnerabilidad de escalada de privilegios local de kernel a SMM en el BIOS versión 303 del ASUS UX360CA. El problema se solucionó en la versión 304.

Descripción del problema

Resumen

El BIOS versión 303 del UX360CA tiene 3 módulos vulnerables que permiten a un atacante con privilegio ring0 sobrescribir memoria física casi arbitraria, incluida la SMRAM, y ejecutar código arbitrario en SMM.

Esos módulos se pueden identificar de la siguiente manera:

Esos módulos son de AMI (fabricante de BIOS) y pueden estar presentes en BIOS de otros OEM.

Vulnerabilidades

Los módulos vulnerables y sus SMI correspondientes son: UsbRt (0x31), SdioSmm (0x40) y NvmeSmm (0x42). Todos esos manejadores de SMI leen la dirección de memoria física 0x40E para obtener una dirección sobre la que trabajar y escriben un byte en esa dirección en caso de error, incluso si se trata de SMRAM.

Por ejemplo, el manejador de SMI de SdioSmm tiene el siguiente aspecto:

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 a INTEL-SA-00057, que está muy bien descrito como Aptiocalypsis. Sin embargo, el BIOS versión 303 para UX360CA no incluye correcciones para ellos.

Explotación

Esto permite a un atacante con acceso de escritura a la memoria física y la instrucción OUT (es decir, los privilegios ring0) sobrescribir el contenido de la SMRAM con los siguientes pasos:

1. Asegurarse de que la dirección física 0x40e sea cero (lo más probable es que ya lo sea)
2. Escribir una dirección de SMRAM, por ejemplo 0x88400000, en la dirección física 0x104
3. Emitir la SMI 0x40
4. Se actualiza 0x88400000+2 con 0x7.

Esto se puede usar para lograr la ejecución de código arbitrario en SMM de la siguiente manera:

1. Encontrar la dirección de la System Management Service Table (SMST) en SMRAM, con los siguientes pasos:
   1. Obtener un rango de direcciones físicas para el código de runtime de UEFI a partir del contenido del valor .Raw en HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. Encontrar la dirección de SMM_CORE_PRIVATE_DATA escaneando la firma 'smmc' en el rango de direcciones.
   3. SMM_CORE_PRIVATE_DATA tiene el puntero a la SMST en el desplazamiento 30h
2. Sobrescribir el puntero a la función SmmLocateProtocol en el desplazamiento d0h de la SMST usando la primitiva de escritura anterior. El valor se actualiza a 0x07070707.
3. Escribir shellcode en la memoria física 0x07070707
4. Disparar otra SMI que llame a Smst->SmmLocateProtocol, como la SMI 0xdf. El shellcode en 0x07070707 se ejecuta en SMM.

La ejecución de código arbitrario en SMM permitiría a un atacante omitir medidas de seguridad del kernel y del hipervisor, como HVCI, como se demuestra en otro informe de vulnerabilidad de SMM, y establecer persistencia actualizando el contenido de la memoria flash SPI (BIOS).

Prueba de concepto (PoC)

El proyecto de demostración adjunto demuestra una explotación exitosa y vuelca el contenido de los MSR que solo son accesibles en SMM y la dirección física de la EPTP. También modifica el código de manejo de salida de VM (VM-exit) de CPUID del hipervisor Hyper-V para devolver una cadena de proveedor del hipervisor alterada.

La PoC se probó en Windows build 18362.1256, con y sin HVCI habilitado.

Una grabación de la explotación exitosa se puede encontrar en YouTube.

Instrucciones de prueba

1. Abrir demo.sln en Visual Studio 2019
2. Compilar la solución para una compilación Debug o Release
3. Copiar el demo.sys compilado al sistema de destino (por ejemplo, C:\users\user\desktop\demo.sys)

En el sistema de destino,

1. Deshabilitar el arranque seguro (Secure Boot) desde el BIOS y reiniciar
2. Habilitar el modo de firma de prueba y reiniciar
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. Crear el servicio para cargar demo.sys
   root@kitploit:~

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

4. Iniciar DebugView y habilitar "Capture Kernel" desde el menú "Capture".
5. Iniciar la demo
   root@kitploit:~

   > sc start demo
   

6. Si tiene éxito, DebugView mostrará los valores de los MSR relacionados con 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
   

Resolución

La corrección consiste en evitar por completo usar el contenido controlado por el usuario cuando apunta al interior de la SMRAM, como se muestra a continuación.

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

Consideraciones

Protección faltante para el hipervisor

La corrección sigue perfectamente las mejores prácticas actuales de la industria y evita el ataque de "confused deputy" (subordinado confundido) que conduce a la corrupción de la SMRAM.

Sin embargo, nótese que no tiene en cuenta las regiones de memoria del hipervisor. Un atacante que conozca la dirección de memoria física donde el hipervisor está cargado o que utilice podría aun así solicitar a la SMI sobrescribir código o datos del hipervisor y lograr la corrupción del hipervisor.

Este es un problema prevalente, de larga data e incluso a nivel de diseño.

Falta de defensa en profundidad

Los problemas reportados se resolvieron, pero hubo algunos problemas en cuanto a la aplicación de la estrategia de defensa en profundidad.

Por ejemplo, la tabla de páginas de SMM tiene un mapeo de identidad con permisos completos de lectura, escritura y ejecución, y la característica SMM_Code_Chk_En no estaba disponible. Eso hizo que la explotación fuera trivial. También noto que el búfer de comunicación de SMM no se verifica con SmmIsBufferOutsideSmmValid() como se encuentra en EDK2, aunque no encontré una SMI explotable.

Creo que esos son problemas comunes entre los OEM y muchas versiones de BIOS. Señalo que si tienes modelos antiguos de cualquier OEM, es poco probable que ese BIOS sea tan seguro como desearías, incluso con sus últimas versiones de BIOS.

Mejoras

Esos problemas no desaparecerán muy pronto, pero me entusiasma ver que la industria está trabajando en una resolución arquitectónica al reducir los privilegios de SMM. Aquí hay algunos de esos trabajos y artículos que puedes consultar:

• Platform Runtime Mechanism (PRM)
  • Presentación (Open-Source Firmware Conference 2020)
  • Especificación (uefi.org)
  • Implementación (edk2-staging)
• Inmersión profunda en System Management Mode: Cómo el aislamiento de SMM refuerza la plataforma
• Requisitos del sistema para System Guard

Cronología

Aquí hay algunos aspectos destacados.

• 2020-12-31 - Reporté la vulnerabilidad
• 2021-01-05 - ASUS confirmó el informe
• 2021-01-18 - ASUS me envió la versión corregida del BIOS para pruebas
• 2021-01-20 - Confirmé la corrección y respondí
• 2021-01-25 - ASUS confirmó mi respuesta
• 2021-03-21 - ASUS publicó la corrección, versión 304
• 2021-03-29 - ASUS emitió una entrada de aviso para CVE-2021-26943

Finalmente, muchas gracias a los equipos de ASUS por mantener el ciclo de comunicación cercano y transparente❤ El proceso general no fue rápido, pero sí bastante libre de frustraciones.