Matthew Garrett, un reconocido desarrollador de kernel Linux, quien recibió en su momento un premio de la Free Software Foundation 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 gestor de arranque sin revocar la firma digital, así como su papel en el reciente incidente con la actualización para Windowslo que provocó que algunas distribuciones dejaran de cargarse Linux, instalado en paralelo con Windows En sistemas con arranque seguro UEFI habilitado. En resumen, tanto Microsoft, que no probó completamente la actualización y la aplicó a sistemas a los que no debía, como los desarrolladores de algunas distribuciones tienen la culpa. Linux, que no actualizó el cargador de arranque GRUB ni el número de generación de SBAT cuando se descubrieron vulnerabilidades en GRUB.
A continuación se muestra una traducción de la nota de Garrett:
Cuando se desarrolló la especificación UEFI Secure Boot, todos sus participantes fueron, digamos, un poco ingenuos. El modelo de seguridad básico de Secure Boot es que todo el código que se ejecuta en un entorno privilegiado a nivel del kernel debe verificarse antes de la ejecución: el firmware verifica el gestor de arranque, el gestor de arranque verifica el kernel, el kernel verifica cualquier código del kernel adicional cargado en tiempo de ejecución, y ahora tenemos un entorno confiable para imponer cualquier otra política de seguridad que queramos. Obviamente, las personas pueden cometer errores, pero la especificación proporcionó una forma de revocar componentes firmados que no eran confiables: simplemente agregue un hash del código que no es confiable a una variable y luego rechace cargar cualquier cosa con ese hash, incluso si estaba firmado. con una clave confiable.
Desafortunadamente, resulta que el problema es la escala. Cada distribución LinuxGRUB, que opera dentro del ecosistema Secure Boot, genera sus propios binarios de gestor de arranque, cada uno con su propio hash. Si se descubre una vulnerabilidad en el código fuente de dicho gestor de arranque, se debe recuperar una gran cantidad de binarios diferentes. El espacio de memoria para almacenar una variable que contenga todos estos hashes es limitado. Simplemente no hay suficiente espacio para agregar un nuevo conjunto de hashes cada vez que se descubre que GRUB (un gestor de arranque escrito originalmente en la era anterior a Secure Boot, con varios analizadores de .img separados y un analizador de fuentes) tiene otro mecanismo para que un atacante ejecute código arbitrario, por lo que se necesitaba otra solución.
Esa solución fue SBAT. El concepto general de SBAT es bastante simple. Cada componente crítico de la cadena de arranque declara una generación de seguridad que se incluye en el binario firmado. Cuando se descubre y soluciona una vulnerabilidad, esta generación aumenta. Luego se puede emitir una actualización que define la generación mínima: los componentes de arranque observarán el siguiente elemento de la cadena, compararán su nombre y número de generación con los almacenados en la variable de firmware y decidirán si ejecutarlo o no en función de eso. . En lugar de revocar una gran cantidad de hashes individuales, podría emitir 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 volvió relevante de repente? SBAT fue desarrollado en colaboración por la comunidad. Linux y Microsoft y Microsoft decidieron lanzar una actualización para Windows, que indicaba a los sistemas que no confiaran en las versiones de GRUB con una generación de seguridad inferior a cierto nivel. Esto se debía a que dichas versiones de GRUB presentaban vulnerabilidades de seguridad reales que permitían a los atacantes romper la cadena de arranque seguro. Windowsy hemos visto ejemplos reales de malware que querían hacer esto (Black Lotus explotó una vulnerabilidad en el gestor de arranque). Windows, pero la vulnerabilidad de GRUB fue igual de efectiva). Desde una perspectiva puramente de seguridad, este es un deseo perfectamente legítimo.
Ahora bien, con respecto al mensaje "Algo salió muy mal" y la imposibilidad de arrancar el sistema como resultado de esta actualización, es Shim quien lo genera, no algún código de Microsoft. Shim tiene en cuenta las actualizaciones de SBAT y, para no infringir los principios de seguridad adoptados por otros gestores de arranque del sistema, y aunque Microsoft haya publicado una actualización de SBAT, es el gestor de arranque el responsable. Linux Como resultado, se niega a ejecutar versiones anteriores de GRUB. Todo funciona como debería.
El problema que la gente ha encontrado es que existen múltiples distribuciones. Linux No se han lanzado versiones de GRUB con una nueva generación de seguridad, por lo que estas versiones de GRUB se consideran inseguras (cabe destacar que GRUB está firmado por las propias distribuciones, no por Microsoft, por lo que no hay ningún retraso introducido externamente). Según el plan de Microsoft, la actualización Windows Se suponía que la actualización aplicaría la actualización SBAT solo a los sistemas que ejecutan únicamente WindowsAdemás, cualquier instalación de arranque dual seguiría siendo vulnerable a ataques hasta que la distribución instalada actualizara GRUB y la generación de SBAT. Desafortunadamente, como ahora es evidente, esto no funcionó como se esperaba, y al menos algunos sistemas de arranque dual aplicaron la actualización, pero el Shim de la distribución se negó a cargar GRUB.
¿Cuál es la conclusión? Microsoft (por razones obvias) no quería Windows Podría ser atacado utilizando una versión vulnerable de GRUB, que podría ser engañada para ejecutar código arbitrario y luego inyectar un bootkit en el kernel. Windows durante el arranque. Microsoft hizo esto lanzando una actualización. WindowsEsta actualización modificó la variable SBAT para indicar que las versiones vulnerables de GRUB no debían arrancar en estos sistemas. El gestor de arranque de primera etapa proporcionado por la distribución Shim leyó esta variable, leyó la partición SBAT de la copia instalada de GRUB, detectó un conflicto y se negó a cargar GRUB con el mensaje "Algo salió muy mal". Esta actualización no estaba destinada a sistemas de arranque dual, pero se aplicó de todos modos.
En general:
1) Microsoft aplicó la actualización a sistemas a los que no debía aplicarse.
2) Algunas distribuciones Linux No se actualizó el gestor de arranque GRUB ni la generación de seguridad SBAT cuando se descubrieron vulnerabilidades en GRUB.
Como resultado, algunas personas no pueden iniciar sus sistemas. Creo que aquí hay mucha gente a quien culpar. Microsoft debería haber realizado más pruebas para garantizar que las instalaciones de arranque dual puedan detectarse con precisión. Pero las distribuciones que suministran gestores de arranque firmados deben asegurarse de actualizarlos y actualizar la generación de seguridad para que coincida, porque de lo contrario proporcionan un vector de ataque que puede usarse para piratear otros sistemas operativos, y eso es una especie de violación del contrato social que lo rodea. todo.
Desafortunadamente, las víctimas aquí son principalmente usuarios finales que se enfrentan al hecho de que el sistema de repente se niega a cargar el sistema operativo que quieren cargar. Esto nunca debería suceder. No creo que preguntar a los usuarios finales si quieren actualizaciones de arranque seguro dé 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 lo que no se puede hacer. No quiero saberlo después de incidentes como este, por lo que comprendo que esté habilitado de forma predeterminada, por lo que apoyo que esté habilitado de manera predeterminada y comparto la elección de Microsoft, excepto por el desafortunado intento de evitar la actualización en sistemas de arranque dual.
En cualquier caso, 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 gestor de arranque significativamente mejor, compatible con una gama más amplia de personas, y que no he tocado en varios años), así que si quieres culpar a alguien, siéntete libre de culparme a mí. Esto es algo que no debería haber sucedido, y a menos que seas Microsoft o una distribución LinuxEntonces no es tu culpa. Lo siento.
Fuente: opennet.ru
