Hace poco compartimos aquí en el blog la noticia sobre el problema que genero una actualización de Microsoft en el arranque dual con las distribuciones de Linux que utilizan GRUB. Sobre el incidente mencionábamos en el artículo que dicha actualización tenía como «finalidad» el abordar una vulnerabilidad del GRUB de hace dos años, «CVE-2022-2601» que permite a los atacantes eludir las protecciones de arranque seguro, pero que lejos de ser un beneficio, termino perjudicando a muchos usuarios.

Días después del suceso, Matthew Garrett, un reconocido desarrollador del kernel de Linux, publico una nota en la cual ha explicado el funcionamiento del mecanismo SBAT.  En ella, menciona que SBAT fue diseñado para bloquear vulnerabilidades en el gestor de arranque sin necesidad de revocar las firmas digitales, y ha sido el elemento central en el reciente incidente causado por una actualización de Windows que afectó a algunas distribuciones de Linux en sistemas con arranque seguro UEFI, impidiendo su arranque.

Según Garrett, tanto Microsoft como algunos desarrolladores de Linux comparten la responsabilidad del problema: Microsoft por no haber probado adecuadamente la actualización en todos los escenarios y los desarrolladores de Linux por no haber actualizado el GRUB y el número de generación SBAT cuando se descubrieron vulnerabilidades en GRUB.

Garrett también menciona que cuando se creó la especificación UEFI Secure Boot, todos los involucrados, en cierta medida, subestimaron su complejidad, ya que

El modelo básico de seguridad de Secure Boot establece que todo el código ejecutado en un entorno privilegiado a nivel del kernel debe ser verificado antes de su ejecución: el firmware verifica el gestor de arranque, el gestor de arranque verifica el kernel, y el kernel verifica cualquier código adicional cargado en tiempo de ejecución. Así, se establece un entorno seguro para aplicar políticas adicionales de seguridad.

Ademas de ello, especifica que aunque exista la posibilidad de «cometer errores» como tal la especificación incluye un mecanismo para revocar componentes firmados no confiables: simplemente se añade el hash del código problemático a una variable, y se rechaza la carga de cualquier código con ese hash, incluso si está firmado con una clave de confianza.

Hasta este punto todo suena bien, pero Garrett menciona que el problema radica en la escala y principalmente en la fragmentación del ecosistema Secure Boot, ya que cada distribución genera sus propios archivos binarios para el gestor de arranque, cada uno con su propio hash.

Es por ello que explica que cuando se encuentra una vulnerabilidad en el código fuente de un gestor de arranque, se necesita revocar una gran cantidad de archivos binarios diferentes. Además, la memoria disponible para almacenar una variable que contenga todos estos hashes es limitada, y no hay suficiente espacio para añadir un nuevo conjunto de hashes cada vez que se descubre una vulnerabilidad en GRUB  y es por ello, era necesaria una solución diferente.

Esa solución fue SBAT.

El concepto de SBAT es relativamente simple: cada componente crítico dentro de la cadena de arranque declara un número de generación de seguridad que se incluye en el binario firmado. Cuando se identifica y corrige una vulnerabilidad, este número de generación aumenta. A partir de ahí, es posible emitir una actualización que establezca la generación mínima aceptable. Los componentes de arranque revisarán este número para determinar si pueden ejecutar el siguiente elemento en la cadena de arranque, comparando el nombre y el número de generación con los valores almacenados en la variable de firmware.

En lugar de tener que revocar numerosos hashes individuales, una sola actualización puede indicar: «Cualquier versión de GRUB con una generación de seguridad inferior a este número es considerada no confiable».

Linux, el verdadero responsable

Garrett menciona que el error que impide que algunos sistemas arranquen tras la actualización, no proviene del código de Microsoft, sino del componente shim del cargador de arranque de Linux.

Aunque Microsoft lanzó la actualización de SBAT, es el cargador de arranque de Linux quien se niega a ejecutar versiones antiguas de GRUB, haciendo que todo funcione como se espera desde un punto de vista técnico.

Es por ello que el verdadero problema radica en que varias distribuciones de Linux no han lanzado versiones actualizadas de GRUB que incorporen las correcciones de seguridad y las nuevas generaciones de SBAT. Esto provoca que dichas versiones de GRUB sean consideradas inseguras, ya que shim bloquea su ejecución.

Es importante notar que GRUB está firmado por las propias distribuciones de Linux, no por Microsoft, lo que elimina cualquier retraso externo en la actualización.

Dada la explicación de Garrett, menciona que Microsoft lanzo su actualización para que se aplicara únicamente en Windows (tal y como debe ser) y el problema fue por parte de las distribuciones que aún manejaban versiones vulnerables y generando el problema con el arranque dual

Finalmente menciona que en este incidente, lamentablemente, las principales víctimas de esta situación son los usuarios finales, quienes se encuentran de repente con que no pueden arrancar el sistema operativo que desean.

Esto es algo que no debería suceder nunca. Aunque entiendo la necesidad de que el arranque seguro UEFI esté habilitado por defecto, y apoyo la decisión de Microsoft en general, es claro que el intento de evitar la actualización en sistemas de arranque dual no funcionó como se esperaba.

Si estás interesado en poder conocer más al respecto, te invito a que consultes la nota original de Matthew Garrett en el siguiente enlace.