Vulnerabilidad de arranque seguro UEFI con GRUB2: 'BootHole'

Desarrolladores de Debian y de otros proyectos de la comunidad Linux han tenido conocimiento recientemente de un problema grave en el gestor de arranque GRUB2 que permite la completa elusión del arranque seguro UEFI. Los detalles completos del problema se describen en el aviso de seguridad de Debian 4735. El propósito de este documento es explicar las consecuencias de esta vulnerabilidad de seguridad y los pasos que se han llevado a cabo para abordarla.

Contexto: ¿qué es el arranque seguro UEFI?

El arranque seguro (SB, por sus siglas en inglés) UEFI es un mecanismo de verificación para asegurar que el código lanzado por el firmware UEFI de una computadora es de confianza. Está diseñado para proteger al sistema frente a la carga y ejecución de código malicioso en las fases tempranas del proceso de arranque, cuando todavía no se ha cargado el sistema operativo.

El funcionamiento del SB se basa en sumas de verificación («checksums») y en firmas criptográficas. Cada programa cargado por el firmware incluye una firma y una suma de verificación y, antes de permitir su ejecución, el firmware comprueba que el programa es de confianza validando la suma de verificación y la firma. Cuando el SB está habilitado en un sistema, no se permite la ejecución de ningún programa que no sea de confianza. Esto impide la ejecución en el entorno UEFI de código inesperado o no autorizado.

La mayoría del hardware x86 viene de fábrica con las claves de Microsoft precargadas, lo que significa que el firmware instalado en estos sistemas confía en los binarios que están firmados por Microsoft. La mayoría de los sistemas modernos se venden con el SB habilitado por lo que, por omisión, no ejecutan código sin firmar. Pero es posible modificar la configuración del firmware para, o bien inhabilitar el SB, o bien instalar claves de firma adicionales.

Debian, como muchos otros sistemas operativos basados en Linux, utiliza un programa llamado shim para extender esta confianza desde el firmware hacia otros programas que necesitamos que estén protegidos en las fases tempranas del arranque: el gestor de arranque GRUB2, el núcleo Linux y las herramientas de actualización del firmware (fwupd y fwupdate).

Encontrados varios fallos en GRUB2

Lamentablemente, se ha encontrado un fallo en el código del gestor de arranque GRUB2 encargado de leer y analizar sintácticamente su configuración (grub.cfg). Este fallo rompe la cadena de confianza; explotando este fallo, es posible escapar del entorno seguro y cargar, en las fases tempranas del arranque, programas sin firmar. Esta vulnerabilidad fue descubierta por investigadores de Eclypsium, que la llamaron BootHole.

En lugar de limitarse a corregir este fallo, los desarrolladores se han visto motivados para llevar a cabo una auditoría en profundidad del código fuente de GRUB2. ¡Habría sido irresponsable corregir un defecto importante sin aprovechar la ocasión para buscar otros! Un equipo de ingenieros ha trabajado conjuntamente durante varias semanas para identificar y corregir una variedad de otros problemas. Hemos encontrado algunos lugares en los que asignaciones internas de memoria podían desbordar las entradas inesperadas proporcionadas, varios lugares más en los que desbordamientos de entero en cálculos matemáticos podían causar problemas y unos pocos lugares en los que se podría usar la memoria después de liberarla. Se han compartido con la comunidad y probado con su ayuda correcciones para todos estos fallos.

De nuevo, consulte el aviso de seguridad de Debian 4735 para una lista completa de los problemas encontrados.

Encontrados fallos también en Linux

Mientras discutían los defectos de GRUB2, los desarrolladores hablaron también sobre dos elusiones encontradas recientemente y corregidas por Jason A. Donenfeld (zx2c4) (1, 2) por las que Linux podría permitir que se sorteara el arranque seguro. Ambas permitían que root reemplazara tablas de ACPI en un sistema asegurado («locked-down»), cuando esto no debería estar permitido. Ya se han publicado correcciones para estos problemas.

Revocación de claves necesaria para corregir la cadena de arranque seguro

Naturalmente, Debian y otros proveedores de sistemas operativos publicarán versiones corregidas de GRUB2 y de Linux. Sin embargo, esto no constituye una solución completa para estos problemas. Actores maliciosos todavía podrían utilizar versiones más antiguas, y vulnerables, para eludir el arranque seguro.

Para evitarlo, el siguiente paso será que Microsoft bloquee esos binarios inseguros de forma que dejen de ejecutarse bajo el SB. Esto se consigue utilizando la lista DBX, una característica de diseño del arranque seguro UEFI. Se ha pedido a todas las distribuciones de Linux que incluyen copias de shim firmadas por Microsoft que proporcionen detalles de los binarios o de las claves involucradas para facilitar este proceso. El fichero con la lista de revocación de UEFI será actualizado para incluir esta información. En algún momento futuro, los sistemas empezarán a utilizar la lista actualizada y rehusarán la ejecución de los binarios vulnerables bajo el arranque seguro.

El cronograma exacto para el despliegue de este cambio no está claro aún. Los vendedores de BIOS/UEFI incluirán la nueva lista de revocación en las compilaciones nuevas del firmware para hardware nuevo en algún momento. Microsoft también puede publicar actualizaciones para sistemas existentes a través de las actualizaciones de Windows («Windows Update»). Algunas distribuciones de Linux pueden publicar actualizaciones por medio de sus propios procesos de actualizaciones de seguridad. Debian no hace esto todavía, pero lo estamos evaluando para el futuro.

¿Cuáles son los efectos de la revocación de claves?

La mayoría de los vendedores son recelosos en cuanto a la aplicación automática de actualizaciones que revoquen claves utilizadas por el arranque seguro. Instalaciones de software con el SB habilitado pueden dejar de arrancar repentinamente, salvo que el usuario tenga cuidado de instalar también todos las actualizaciones de software necesarias. En los sistemas con arranque dual Windows/Linux puede dejar de arrancar Linux. Los medios de instalación antiguos y «en vivo» («live media»), por supuesto, tampoco arrancarán, haciendo, potencialmente, que sea más trabajoso recuperar sistemas.

Hay dos maneras obvias de restablecer un sistema que no arranque por este motivo:

Es posible que ambas parezcan opciones sencillas, pero pueden consumir mucho tiempo para usuarios con varios sistemas. Además, tenga en cuenta que la habilitación e inhabilitación del arranque seguro requiere, por diseño, acceso directo a la máquina. Normalmente no es posible hacer estos cambios por otros medios que no sean la configuración del firmware de la computadora. Los servidores remotos pueden precisar de un cuidado especial por esta razón.

Por estos motivos, se recomienda encarecidamente que todos los usuarios y usuarias de Debian presten atención a la instalación de todas las actualizaciones recomendadas para sus sistemas tan pronto como sea posible, para reducir la probabilidad de encontrarse con problemas en el futuro.

Paquetes actualizados

Nota: los sistemas con Debian 9 (stretch) y anteriores no recibirán necesariamente actualizaciones para este problema, ya que Debian 10 (buster) fue la primera versión de Debian con soporte para el arranque seguro de UEFI.

Se han actualizado las versiones firmadas de todos estos paquetes, aunque no fueran necesarios otros cambios. Debian ha tenido que generar una nueva clave/certificado de firma para sus propios paquetes de arranque seguro. La etiqueta del certificado antiguo era Debian Secure Boot Signer (huella dactilar f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c); el certificado nuevo es Debian Secure Boot Signer 2020 (3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31).

Hay cinco paquetes fuente en Debian que se van a actualizar debido a los cambios en el arranque seguro UEFI descritos aquí:

1. GRUB2

Para la distribución «estable» Debian 10 (buster), hay disponibles versiones actualizadas de los paquetes de GRUB2 de Debian a través del archivo debian-security. Muy pronto habrá versiones corregidas en el archivo para distribuciones en desarrollo de Debian («inestable» y «en pruebas»).

2. Linux

Para la distribución «estable» Debian 10 (buster), hay disponibles versiones actualizadas de los paquetes de linux de Debian a través de buster-proposed-updates y se incluirán en la próxima versión 10.5. También hay paquetes nuevos en el archivo para distribuciones en desarrollo de Debian («inestable» y «en pruebas»). Esperamos tener también paquetes corregidos subidos a buster-backports pronto.

3. Shim

Debido a la manera en que funciona la gestión de claves para el arranque seguro de Debian, Debian no necesita revocar sus paquetes existentes de shim firmados por Microsoft. Sin embargo, es necesario recompilar las versiones firmadas de los paquetes de shim-helper para utilizar la clave de firma nueva.

Para la distribución «estable» Debian 10 (buster), hay disponibles versiones actualizadas de los paquetes de shim de Debian a través de buster-proposed-updates y se incluirán en la próxima versión 10.5. También hay paquetes nuevos en el archivo para distribuciones en desarrollo de Debian («inestable» y «en pruebas»).

4. Fwupdate

Para la distribución «estable» Debian 10 (buster), hay disponibles versiones actualizadas de los paquetes de fwupdate de Debian a través de buster-proposed-updates y se incluirán en la próxima versión 10.5. fwupdate ya había sido eliminado de «inestable» y de «en pruebas» hace un tiempo, en favor de fwupd.

5. Fwupd

Para la distribución «estable» Debian 10 (buster), hay disponibles versiones actualizadas de los paquetes de fwupd de Debian a través de buster-proposed-updates y se incluirán en la próxima versión 10.5. También hay paquetes nuevos en el archivo para distribuciones en desarrollo de Debian («inestable» y «en pruebas»).

Debian 10.5 (buster), instalación actualizada y medios «en vivo» («live media»)

Todas las correcciones descritas aquí se incluirán en la versión Debian 10.5 (buster), cuya publicación está prevista el 1 de agosto de 2020. Por lo tanto, la 10.5 sería una buena opción para los usuarios y usuarias que esperen medios de instalación y «en vivo» de Debian. Las imágenes anteriores pueden dejar de funcionar con arranque seguro en el futuro a medida que las revocaciones se vayan propagando.

Más información

En la wiki de Debian hay mucha más información sobre la configuración del arranque seguro UEFI, consulte https://wiki.debian.org/SecureBoot.

Otros recursos sobre este tema incluyen: