SmmExploit

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.

Issue Description

Zusammenfassung

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:

Diese Module stammen von AMI (BIOS-Hersteller) und können in anderen OEM-BIOSen vorhanden sein.

Schwachstellen

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.

Ausnutzung

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:

1. Stellen Sie sicher, dass die physische Adresse 0x40e null ist (was höchstwahrscheinlich bereits der Fall ist)
2. Schreiben Sie eine Adresse von SMRAM, z.B. 0x88400000, an die physische Adresse 0x104
3. Lösen Sie das SMI 0x40 aus
4. 0x88400000+2 wird mit 0x7 aktualisiert.

Dies kann verwendet werden, um eine beliebige Codeausführung im SMM zu erreichen, wie folgt:

1. Finden Sie die Adresse der System Management Service Table (SMST) im SMRAM mit den folgenden Schritten:
   1. Ermitteln Sie einen physischen Adressbereich für den UEFI-Laufzeitcode aus dem Inhalt des .Raw-Werts in HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved
   2. Finden Sie die Adresse von SMM_CORE_PRIVATE_DATA durch Scannen der 'smmc'-Signatur im Adressbereich.
   3. SMM_CORE_PRIVATE_DATA enthält den Zeiger auf die SMST an Offset 30h
2. Überschreiben Sie den Zeiger auf die SmmLocateProtocol-Funktion an Offset d0h der SMST mit dem obigen Schreibprimitive. Der Wert wird auf 0x07070707 aktualisiert.
3. Schreiben Sie Shellcode in den physischen Speicher 0x07070707
4. Lösen Sie ein weiteres SMI aus, das Smst->SmmLocateProtocol aufruft, z.B. SMI 0xdf. Der Shellcode an 0x07070707 wird im SMM ausgeführt.

Die 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.

Proof of Concept (PoC)

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.

Testanweisungen

1. Öffnen Sie die Datei demo.sln in Visual Studio 2019
2. Erstellen Sie die Projektmappe für Debug- oder Release-Build
3. Kopieren Sie die kompilierte demo.sys auf das Zielsystem (z.B. C:\users\user\desktop\demo.sys)

Auf dem Zielsystem:

1. Deaktivieren Sie Secure Boot im BIOS und starten Sie neu
2. Aktivieren Sie den Testsignierungsmodus und starten Sie neu
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. Erstellen Sie den Dienst zum Laden von demo.sys
   root@kitploit:~

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

4. Starten Sie DebugView und aktivieren Sie "Capture Kernel" im Menü "Capture".
5. Starten Sie das Demo
   root@kitploit:~

   > sc start demo
   

6. Bei Erfolg zeigt DebugView Werte von SMM-bezogenen MSRs an.
   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
   

Lösung

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

Überlegungen

Fehlender Schutz für Hypervisor

Die Behebung folgt perfekt der aktuellen Branchenbest Practice und verhindert den Confused-Deputy-Angriff, der zur SMRAM-Korruption führt.

Beachten Sie jedoch, dass es keine Rücksicht auf Hypervisor-Speicherbereiche nimmt. Ein Angreifer mit Kenntnis der physischen Speicheradresse, an der der Hypervisor geladen ist oder verwendet wird, könnte immer noch das SMI anfordern, um Hypervisor-Code oder -Daten zu überschreiben und die Hypervisor-Korruption zu erreichen.

Dies ist ein weit verbreitetes, seit langem bestehendes und sogar designbedingtes Problem.

Fehlende Defense-in-Depth

Die gemeldeten Probleme wurden behoben, aber es gab einige Probleme in Bezug auf die Umsetzung der Defense-in-Depth-Strategie.

Zum Beispiel ist die SMM-Seitentabelle identitätsabbildend mit vollständigen Lese-, Schreib- und Ausführungsberechtigungen, und die Funktion SMM_Code_Chk_En war nicht verfügbar. Dies machte die Ausnutzung trivial. Ich stelle auch fest, dass der SMM-Kommunikationspuffer nicht mit SmmIsBufferOutsideSmmValid() wie in EDK2 zu finden überprüft wird, obwohl ich kein ausnutzbares SMI gefunden habe.

Ich glaube, dass dies häufige Probleme bei OEMs und vielen BIOS-Versionen sind. Ich weise darauf hin, dass, wenn Sie alte Modelle von irgendeinem OEM verwenden, dieses BIOS wahrscheinlich nicht so sicher ist, wie Sie es sich wünschen, selbst mit den neuesten BIOS-Versionen.

Verbesserungen

Diese Probleme werden nicht so schnell verschwinden, aber ich bin begeistert zu sehen, dass die Industrie an einer architektonischen Lösung arbeitet, indem sie die SMM-Berechtigungen reduziert. Hier sind einige dieser Arbeiten und Artikel, die Sie sich ansehen können:

• Platform Runtime Mechanism (PRM)
  • Präsentation (Open-Source Firmware Conference 2020)
  • Spezifikation (uefi.org)
  • Implementierung (edk2-staging)
• Systemverwaltungsmodus Deep Dive: Wie SMM-Isolation die Plattform härtet
• Systemanforderungen für System Guard

Zeitplan

Hier einige Höhepunkte.

• 2020-12-31 - Ich habe die Schwachstelle gemeldet
• 2021-01-05 - ASUS hat den Bericht bestätigt
• 2021-01-18 - ASUS hat mir die behobene BIOS-Version zum Testen geschickt
• 2021-01-20 - Ich habe die Behebung bestätigt und zurückgemeldet
• 2021-01-25 - ASUS hat meine Antwort bestätigt
• 2021-03-21 - ASUS hat die Behebung veröffentlicht, Version 304
• 2021-03-29 - ASUS hat einen Sicherheitshinweis für CVE-2021-26943 herausgegeben

Abschließend ein großes Dankeschön an die ASUS-Teams für die enge und transparente Kommunikation❤ Der gesamte Prozess war nicht schnell, sondern eher frustfrei.