Matthew Garrett, un conocido desarrollador del n\u00facleo de Linux, quien en su momento recibi\u00f3 un premio del FOSS por su contribuci\u00f3n al desarrollo del software libre, habl\u00f3 sobre la esencia del mecanismo SBAT (Secure Boot Advanced Targeting), creado para bloquear vulnerabilidades en el cargador sin revocar la firma digital, as\u00ed como sobre su papel en el reciente incidente con una actualizaci\u00f3n de Windows que llev\u00f3 a la interrupci\u00f3n 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\u00f3 completamente la actualizaci\u00f3n y la aplic\u00f3 a sistemas a los que no deb\u00eda aplicarse, como algunos desarrolladores de distribuciones de Linux, que no actualizaron el cargador GRUB y la versi\u00f3n de SBAT cuando se descubrieron vulnerabilidades en GRUB. <\/p>\n
A continuaci\u00f3n se presenta la traducci\u00f3n de la nota de Garrett: <\/p>\n
\nDurante el desarrollo de la especificaci\u00f3n de UEFI Secure Boot, todos los participantes eran, digamos, un poco inocentes. El modelo de seguridad principal de Secure Boot establece que todo el c\u00f3digo que se ejecute en un entorno privilegiado a nivel de n\u00facleo debe ser verificado antes de su ejecuci\u00f3n: el firmware verifica el cargador, el cargador verifica el n\u00facleo, el n\u00facleo verifica cualquier c\u00f3digo adicional que se cargue en tiempo de ejecuci\u00f3n, y ahora tenemos un entorno de confianza para imponer cualquier otra pol\u00edtica de seguridad que deseemos. Es evidente que las personas pueden cometer errores, pero la especificaci\u00f3n inclu\u00eda un m\u00e9todo para revocar componentes firmados que resultaron ser poco confiables: simplemente agregue el hash del c\u00f3digo no confiable a una variable y luego rechace cualquier carga con ese hash, incluso si est\u00e1 firmado con una clave de confianza. <\/p>\n
Lamentablemente, como se ha descubierto, el problema radica en la escala. Cada distribuci\u00f3n 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\u00f3digo fuente de dicho gestor de arranque, es necesario revocar una gran cantidad de archivos binarios diferentes. Adem\u00e1s, la capacidad de almacenamiento para la variable que contiene todos estos hashes es limitada. Simplemente no hay suficiente espacio para a\u00f1adir un nuevo conjunto de hashes cada vez que se determina que GRUB (el gestor de arranque, que fue escrito en una \u00e9poca en la que no se practicaba la protecci\u00f3n de arranque y que tiene varios analizadores de im\u00e1genes img, as\u00ed como un analizador de fuentes) tiene otro mecanismo que permite a un atacante hacer que ejecute c\u00f3digo arbitrario, por lo que se necesita una soluci\u00f3n diferente. <\/p>\n
La soluci\u00f3n a esto fue SBAT. El concepto general de SBAT es bastante simple. Cada componente importante en la cadena de arranque declara una generaci\u00f3n de seguridad, que se incluye en el archivo binario firmado. Cuando se detecta y se corrige una vulnerabilidad, esta generaci\u00f3n se incrementa. Luego, se puede emitir una actualizaci\u00f3n que defina la generaci\u00f3n m\u00ednima: los componentes de arranque mirar\u00e1n el siguiente elemento en la cadena, comparar\u00e1n su nombre y n\u00famero de generaci\u00f3n con los que se almacenan en la variable de firmware y decidir\u00e1n si ejecutarlo o no en funci\u00f3n de esto. En lugar de revocar una gran cantidad de hashes individuales, se puede emitir una sola actualizaci\u00f3n que simplemente diga: 'Cualquier versi\u00f3n de GRUB con una generaci\u00f3n de seguridad inferior a este n\u00famero se considera no confiable'. <\/p>\n
\u00bfPor qu\u00e9 esto se ha vuelto relevante? SBAT fue desarrollado conjuntamente por la comunidad de Linux y Microsoft, y Microsoft decidi\u00f3 lanzar una actualizaci\u00f3n para Windows que indicara a los sistemas no confiar en versiones de GRUB con una generaci\u00f3n de seguridad por debajo de un cierto nivel. Esto se hizo porque estas versiones de GRUB ten\u00edan vulnerabilidades de seguridad reales que permit\u00edan 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\u00f3 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\u00edtimo. <\/p>\n
Ahora, en cuanto al mensaje 'Algo sali\u00f3 muy mal' y la imposibilidad de arrancar como resultado de esta actualizaci\u00f3n. Es emitido por shim, y no por alg\u00fan c\u00f3digo de Microsoft. Shim tiene en cuenta las actualizaciones de SBAT, y, para no modificar los principios de seguridad aceptados por otros cargadores en el sistema, aunque Microsoft tambi\u00e9n lanz\u00f3 una actualizaci\u00f3n de SBAT, es el cargador de Linux el que finalmente se niega a ejecutar versiones antiguas de GRUB. Todo funciona tal como deber\u00eda. <\/p>\n
El problema al que se enfrentan las personas es que varias distribuciones de Linux no han lanzado versiones de GRUB con una generaci\u00f3n de seguridad m\u00e1s nueva, y por lo tanto, estas versiones de GRUB se consideran inseguras (es relevante se\u00f1alar que GRUB est\u00e1 firmado por las propias distribuciones, no por Microsoft, por lo que aqu\u00ed no hay ning\u00fan atraso importado desde el exterior). Seg\u00fan el dise\u00f1o de Microsoft, la actualizaci\u00f3n de Windows Update deber\u00eda haber aplicado la actualizaci\u00f3n de SBAT solo a sistemas que funcionan solo con Windows, y cualquier instalaci\u00f3n de arranque dual seguir\u00eda siendo vulnerable a ataques hasta que la distribuci\u00f3n instalada no actualizara GRUB y la generaci\u00f3n de SBAT. Desafortunadamente, como ahora es evidente, esto no funcion\u00f3 como se pretend\u00eda, y, al menos, algunos sistemas de arranque dual aplicaron la actualizaci\u00f3n, mientras que shim de esta distribuci\u00f3n se neg\u00f3 a cargar GRUB de esa distribuci\u00f3n. <\/p>\n
\u00bfCu\u00e1l es el resultado? Microsoft (por razones obvias) no quer\u00eda que Windows pudiera ser atacado utilizando una versi\u00f3n vulnerable de GRUB, que podr\u00eda ser enga\u00f1ada para ejecutar c\u00f3digo arbitrario y luego inyectar un bootkit en el n\u00facleo de Windows durante el arranque. Microsoft logr\u00f3 esto al lanzar una actualizaci\u00f3n de Windows que actualiz\u00f3 la variable SBAT, indicando que las versiones vulnerables de GRUB no deb\u00edan cargarse en estos sistemas. El cargador de primer etapa proporcionado por la distribuci\u00f3n Shim le\u00eda esta variable, le\u00eda la partici\u00f3n SBAT de la copia instalada de GRUB, comprend\u00eda que hab\u00eda un conflicto y se negaba a cargar grub con el mensaje \u00abAlgo sali\u00f3 muy mal\u00bb. Esta actualizaci\u00f3n no deb\u00eda aplicarse a los sistemas con doble arranque, pero a\u00fan as\u00ed se aplicaba. <\/p>\n
En resumen: <\/p>\n
1) Microsoft aplic\u00f3 la actualizaci\u00f3n a sistemas a los que no deber\u00eda haberse aplicado <\/p>\n
2) Algunas distribuciones de Linux no actualizaron el cargador GRUB y la generaci\u00f3n de seguridad SBAT cuando se detectaron vulnerabilidades en GRUB. <\/p>\n
Como resultado, algunas personas no pueden cargar sus sistemas. Creo que hay muchos culpables aqu\u00ed. Microsoft deber\u00eda haber realizado m\u00e1s pruebas para asegurarse de que las instalaciones de arranque dual puedan ser identificadas con precisi\u00f3n. Pero tambi\u00e9n las distribuciones que proporcionan cargadores firmados deben asegurarse de actualizarlos y actualizar su generaci\u00f3n 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\u00f3n del contrato social en torno a todo esto. <\/p>\n
Desafortunadamente, las v\u00edctimas aqu\u00ed son en su mayor\u00eda usuarios finales que se encuentran con que el sistema de repente se niega a cargar el sistema operativo que desean iniciar. Esto nunca deber\u00eda 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\u00eda de los usuarios finales, tambi\u00e9n es algo que no quieres descubrir despu\u00e9s de incidentes como este, por lo que simpatizo con el hecho de que est\u00e9 habilitado por defecto, as\u00ed que apoyo su inclusi\u00f3n por defecto y comparto la decisi\u00f3n de Microsoft, salvo por el fallido intento de evitar actualizaciones en sistemas de arranque dual. <\/p>\n
De todos modos, estuve muy involucrado en la implementaci\u00f3n de este mecanismo para Linux en 2012 y escrib\u00ed el primer prototipo de Shim (que ahora es un cargador mucho mejor, respaldado por un grupo m\u00e1s amplio de personas, y al que no he tocado en varios a\u00f1os), as\u00ed que si quieren culpar a alguien, no duden en culparme. Esto no deber\u00eda haber sucedido, y si no eres Microsoft o una distribuci\u00f3n de Linux, no es tu culpa. Lo siento. <\/p><\/blockquote>\n