Definición de SBAT (Secure Boot Advanced Targeting)
- Cuando se definió por primera vez UEFI Secure Boot, todos los involucrados fueron algo ingenuos
- El modelo de seguridad básico de Secure Boot es que todo el código que se ejecuta en un entorno con privilegios a nivel de kernel debe verificarse antes de ejecutarse
- Incluye una forma de revocar componentes firmados cuando se descubren vulnerabilidades
- Sin embargo, como todas las distribuciones de Linux que operan dentro del ecosistema de Secure Boot generan sus propios binarios de bootloader, cuando se identifica una vulnerabilidad hay muchos binarios que deben revocarse
- Como el espacio para almacenar hashes es limitado, se desarrolló SBAT
Cómo funciona SBAT
- Todos los componentes importantes de la cadena de arranque declaran una generación de seguridad incluida en el binario firmado
- Cuando se identifica y corrige una vulnerabilidad, esa generación se incrementa
- A través de una actualización se puede definir una generación mínima
- Un componente de arranque revisa el siguiente elemento de la cadena y compara su nombre y número de generación con lo almacenado en una variable de firmware para decidir si debe ejecutarlo
- En lugar de revocar muchos hashes individuales, se puede enviar una sola actualización que diga que no se deben confiar las versiones de
grub con una generación de seguridad igual o inferior a un número determinado
La causa del problema reciente
- Microsoft publicó una actualización de Windows para dejar de confiar en versiones de
grub con una generación de seguridad por debajo de cierto nivel
- Esto se debe a que esas versiones de
grub tenían vulnerabilidades de seguridad reales que podían comprometer la cadena de Secure Boot de Windows
- El problema es que algunas distribuciones de Linux todavía no habían ofrecido una versión de
grub con la nueva generación de seguridad
- La intención de Microsoft era aplicar la actualización de SBAT solo a sistemas con únicamente Windows, pero eso no funcionó como se esperaba
Resumen
- Microsoft impulsó una actualización para impedir que se pudiera atacar Windows usando versiones vulnerables de
grub
- Se suponía que esta actualización no debía aplicarse a sistemas con dual boot, pero esa condición fue ignorada
- Algunas distribuciones de Linux no habían actualizado el código de
grub ni la generación de seguridad de SBAT
- Como resultado, algunos usuarios ya no pudieron arrancar sus sistemas
A quién culpar
- Microsoft debió haber hecho más pruebas para identificar correctamente las configuraciones con dual boot
- Pero también las distribuciones que entregan bootloaders firmados deben actualizarlos y actualizar la generación de seguridad
- Esto se debe a que pueden proporcionar un vector que se use para atacar otros sistemas operativos
Conclusión
- Es lamentable que los usuarios finales que de repente ya no pudieron arrancar el sistema operativo que querían hayan terminado siendo las víctimas
- Esto es algo que nunca debió pasar
- Aunque UEFI Secure Boot puede sentirse como algo que no aporta beneficios a la mayoría de los usuarios finales, tampoco quieres descubrir después que lo necesitabas, así que entiendo la decisión de Microsoft de dejarlo activado por defecto
- Salvo por el fallido intento de evitar la actualización en sistemas con dual boot, entiendo la decisión de Microsoft
Opinión de GN⁺
- Este incidente muestra lo difícil que es equilibrar la seguridad y la experiencia de usuario
- Tanto Microsoft como las distribuciones de Linux están haciendo lo posible por proteger a los usuarios, pero en el proceso la experiencia de usuario puede verse afectada
- En el caso de quienes usan sistemas con dual boot, es más probable que enfrenten este tipo de problemas
- Por eso, para quienes usan dual boot es importante mantener ambos sistemas operativos en sus versiones más recientes y actualizarlos con regularidad
- A largo plazo, parece necesario contar con una mejor colaboración y coordinación entre las comunidades de Linux y Windows
1 comentarios
Opinión de Hacker News
gruby distribuyera por su cuenta la actualización de SBATshim, así que me pregunto qué salió malshimo de Secure Boot; me gustaría que dijeran exactamente qué falló y cómo resolverlosuspend-to-hiberfile.sysy con actualizaciones que rompíangrubgrubrechazado estaba completamente sin parchear, o si la distribución lo parcheó sin actualizar la "generación de seguridad"grubdesde Windows, o si basta con desactivar Secure Boot, arrancar Linux, actualizar y volver a activarlogrubparece razonable, pero yo solo uso Windows para juegos y un único software heredado, y lo uso sin acceso a la red