Matthew Garrett, un conocido desarrollador del núcleo de Linux, quien en su momento recibió un premio del FOSS por su contribución al desarrollo del software libre, habló sobre la esencia del mecanismo SBAT (Secure Boot Advanced Targeting), creado para bloquear vulnerabilidades en el cargador sin revocar la firma digital, así como sobre su papel en el reciente incidente con una actualización de Windows que llevó a la interrupción del arranque de algunas distribuciones de Linux instaladas junto a Windows en sistemas con UEFI Secure Boot habilitado. En resumen, son responsables tanto la empresa Microsoft, que no probó completamente la actualización y la aplicó a sistemas a los que no debía aplicarse, como algunos desarrolladores de distribuciones de Linux, que no actualizaron el cargador GRUB y la versión de SBAT cuando se descubrieron vulnerabilidades en GRUB.
A continuación se presenta la traducción de la nota de Garrett:
Cuando se estaba desarrollando la especificación de UEFI Secure Boot, todos sus participantes eran, digámoslo de alguna manera, un poco ingenuos. El modelo de seguridad fundamental de Secure Boot implica que todo el código que se ejecuta en un entorno privilegiado a nivel de núcleo debe ser verificado antes de su ejecución: el firmware verifica el cargador, el cargador verifica el núcleo, el núcleo verifica cualquier código adicional cargado durante la ejecución, y ahora tenemos un entorno de confianza para imponernos cualquier otra política de seguridad que deseemos. Obviamente, las personas pueden cometer errores, pero en la especificación se previó un método para revocar componentes firmados que resulten ser no confiables: simplemente añada el hash del código no confiable a una variable y luego se niega a cargar cualquier cosa con ese hash, incluso si está firmado con una clave de confianza.
Lamentablemente, como se ha descubierto, el problema radica en la escala. Cada distribución de Linux que opera en el ecosistema Secure Boot genera sus propios archivos binarios de arranque, y cada uno de ellos tiene su propio hash. Si se encuentra una vulnerabilidad en el código fuente de dicho gestor de arranque, es necesario revocar una gran cantidad de archivos binarios diferentes. Además, la capacidad de almacenamiento para la variable que contiene todos estos hashes es limitada. Simplemente no hay suficiente espacio para añadir un nuevo conjunto de hashes cada vez que se determina que GRUB (el gestor de arranque, que fue escrito en una época en la que no se practicaba la protección de arranque y que tiene varios analizadores de imágenes img, así como un analizador de fuentes) tiene otro mecanismo que permite a un atacante hacer que ejecute código arbitrario, por lo que se necesita una solución diferente.
Esta solución es SBAT. La idea general de SBAT es bastante simple. Cada componente importante en la cadena de arranque declara una generación de seguridad que se incluye en el archivo binario firmado. Cuando se detecta y corrige una vulnerabilidad, esta generación se incrementa. Luego se puede lanzar una actualización que determine la generación mínima: los componentes de arranque mirarán el siguiente elemento en la cadena, compararán su nombre y número de generación con los que se almacenan en la variable de firmware y decidirán si lo ejecutan o no en función de esto. En lugar de revocar una gran cantidad de hashes individuales, se puede lanzar una única actualización que simplemente diga: 'Cualquier versión de GRUB con una generación de seguridad inferior a este número se considera no confiable'.
¿Por qué esto se ha vuelto relevante? SBAT fue desarrollado conjuntamente por la comunidad de Linux y Microsoft, y Microsoft decidió lanzar una actualización para Windows que indicara a los sistemas no confiar en versiones de GRUB con una generación de seguridad por debajo de un cierto nivel. Esto se hizo porque estas versiones de GRUB tenían vulnerabilidades de seguridad reales que permitían a los atacantes comprometer la cadena de arranque seguro de Windows, y hemos visto ejemplos reales de malware que intentaron hacer esto (Black Lotus utilizó una vulnerabilidad en el gestor de arranque de Windows, pero la vulnerabilidad en GRUB era igualmente efectiva). Si lo miramos puramente desde el punto de vista de la seguridad, es un deseo completamente legítimo.
Ahora, en cuanto al mensaje «Algo salió mal» y a la imposibilidad de arrancar como resultado de esta actualización. Lo genera shim, y no algún código de Microsoft. Shim tiene en cuenta las actualizaciones de SBAT y, para no violar los principios de seguridad adoptados por otros cargadores en el sistema, aunque Microsoft lanzó una actualización de SBAT, es el cargador de Linux que, como resultado, se niega a arrancar las versiones antiguas de GRUB. Todo funciona como se supone que debe.
El problema al que se enfrentan las personas es que varias distribuciones de Linux no han lanzado versiones de GRUB con una generación de seguridad más nueva, y por lo tanto, estas versiones de GRUB se consideran inseguras (es relevante señalar que GRUB está firmado por las propias distribuciones, no por Microsoft, por lo que aquí no hay ningún atraso importado desde el exterior). Según el diseño de Microsoft, la actualización de Windows Update debería haber aplicado la actualización de SBAT solo a sistemas que funcionan solo con Windows, y cualquier instalación de arranque dual seguiría siendo vulnerable a ataques hasta que la distribución instalada no actualizara GRUB y la generación de SBAT. Desafortunadamente, como ahora es evidente, esto no funcionó como se pretendía, y, al menos, algunos sistemas de arranque dual aplicaron la actualización, mientras que shim de esta distribución se negó a cargar GRUB de esa distribución.
¿Cuál es la conclusión? Microsoft (por razones obvias) no quería que Windows pudiera ser atacado con una versión de GRUB vulnerable, que podría engañarse para ejecutar código arbitrario y luego inyectar un bootkit en el núcleo de Windows durante el arranque. Microsoft hizo esto lanzando una actualización de Windows que actualizó la variable SBAT, indicando que las versiones vulnerables de GRUB no deben cargarse en esos sistemas. El cargador de arranque de primera etapa proporcionado por la distribución leía esta variable, leía la sección SBAT de la copia instalada de GRUB, entendía que había un conflicto y se negaba a cargar grub con el mensaje «Algo salió mal». Esta actualización no debería haberse aplicado a sistemas de arranque dual, pero aún así fue aplicada.
En resumen:
1) Microsoft aplicó la actualización a sistemas a los que no debería haberse aplicado
2) Algunas distribuciones de Linux no actualizaron el cargador GRUB y la generación de seguridad SBAT cuando se detectaron vulnerabilidades en GRUB.
Como resultado, algunas personas no pueden cargar sus sistemas. Creo que hay muchos culpables aquí. Microsoft debería haber realizado más pruebas para asegurarse de que las instalaciones de arranque dual puedan ser identificadas con precisión. Pero también las distribuciones que proporcionan cargadores firmados deben asegurarse de actualizarlos y actualizar su generación de seguridad para cumplir con esto, porque de lo contrario proporcionan un vector de ataque que puede ser utilizado para hackear otros sistemas operativos, lo que representa una especie de violación del contrato social en torno a todo esto.
Desafortunadamente, las víctimas aquí son en su mayoría usuarios finales que se encuentran con que el sistema de repente se niega a cargar el sistema operativo que desean iniciar. Esto nunca debería haber ocurrido. No creo que encuestar a los usuarios finales sobre si quieren actualizaciones del sistema de arranque seguro arroje un buen resultado, y aunque me inclino vagamente a pensar que el arranque seguro UEFI no es algo que beneficie a la mayoría de los usuarios finales, también es algo que no quieres descubrir después de incidentes como este, por lo que simpatizo con el hecho de que esté habilitado por defecto, así que apoyo su inclusión por defecto y comparto la decisión de Microsoft, salvo por el fallido intento de evitar actualizaciones en sistemas de arranque dual.
De todos modos, estuve muy involucrado en la implementación de este mecanismo para Linux en 2012 y escribí el primer prototipo de Shim (que ahora es un cargador mucho mejor, respaldado por un grupo más amplio de personas, y al que no he tocado en varios años), así que si quieren culpar a alguien, no duden en culparme. Esto no debería haber sucedido, y si no eres Microsoft o una distribución de Linux, no es tu culpa. Lo siento.
Fuente: opennet.ru
