Imágenes Getty
El martes pasado, muchos usuarios de Linux (muchos de ellos con paquetes lanzados este mismo año) empezaron a informar que sus dispositivos no arrancaban. En lugar de ello, recibían un críptico mensaje de error que incluía la frase: “Algo ha ido muy mal”.
La causa: una actualizar Microsoft lo publicó como parte de su lanzamiento de parches mensuales. Su objetivo era cerrar un Vulnerabilidad de dos años en COMIDAun cargador de arranque de código abierto que se utiliza para iniciar muchos dispositivos Linux. La vulnerabilidad, con una calificación de gravedad de 8,6 sobre 10, permitió a los piratas informáticos eludir el arranque seguro, el estándar de la industria para garantizar que los dispositivos que ejecutan Windows u otros sistemas operativos no carguen firmware o software malicioso durante el proceso de arranque. CVE-2022-2601 se descubrió en 2022, pero por razones poco claras, Microsoft la parcheó recién el martes pasado.
Varias distribuciones, tanto nuevas como antiguas, se vieron afectadas
La actualización del martes dejó a los dispositivos de arranque dual (es decir, aquellos configurados para ejecutar tanto Windows como Linux) sin la posibilidad de arrancar en este último cuando se aplicaba el Arranque Seguro. Cuando los usuarios intentaban cargar Linux, recibían el mensaje: “Error al verificar los datos de shim SBAT: Violación de la Política de Seguridad. Algo ha ido muy mal: Falló la autocomprobación de SBAT: Violación de la Política de Seguridad”. Casi inmediatamente apoyo y discusión foros Iluminado con informes del falla.
“Tenga en cuenta que Windows dice que esta actualización no se aplicará a los sistemas que arranquen de forma dual Windows y Linux”, escribió una persona frustrada. “Obviamente, esto no es cierto y probablemente dependa de la configuración de su sistema y de la distribución que se esté ejecutando. Parece haber hecho que algunos cargadores de arranque efi shim de Linux sean incompatibles con cargadores de arranque efi microcrap (por eso funciona cambiar de MS efi a 'otro SO' en la configuración efi). Parece que Mint tiene una versión shim que MS SBAT no reconoce”.
Los informes indican que varias distribuciones, incluidas Debian, Ubuntu, Linux Mint, Zorin OS y Puppy Linux, están afectadas. Microsoft aún no ha reconocido públicamente el error, no ha explicado cómo no se detectó durante las pruebas ni ha proporcionado orientación técnica a los afectados. Los representantes de la empresa no respondieron a un correo electrónico en el que se solicitaban respuestas.
El boletín de Microsoft para CVE-20220-2601 explicó que la actualización instalaría un SBAT—un mecanismo de Linux para revocar varios componentes en la ruta de arranque— pero solo en dispositivos configurados para ejecutar solo Windows. De esa manera, el Arranque Seguro en dispositivos Windows ya no sería vulnerable a ataques que cargaran un paquete GRUB que explotara la vulnerabilidad. Microsoft aseguró a los usuarios que sus sistemas de arranque dual no se verían afectados, aunque advirtió que los dispositivos que ejecutan versiones anteriores de Linux podrían experimentar problemas.
“El valor SBAT no se aplica a los sistemas de arranque dual que arrancan tanto Windows como Linux y no debería afectar a estos sistemas”, decía el boletín. “Es posible que las ISO de distribuciones Linux más antiguas no arranquen. Si esto ocurre, póngase en contacto con su proveedor de Linux para obtener una actualización”.
De hecho, la actualización tiene Se ha aplicado a dispositivos que arrancan tanto Windows como Linux. Esto no solo incluye dispositivos de arranque dual, sino también dispositivos Windows que pueden arrancar Linux desde un Imagen ISOuna unidad USB o un medio óptico. Además, muchos de los sistemas afectados ejecutan versiones de Linux lanzadas recientemente, incluidas Ubuntu 24.04 y Debian 12.6.0.
¿Y ahora qué?
Dado que Microsoft mantiene el silencio, los afectados por el fallo se han visto obligados a buscar sus propios remedios. Una opción es acceder a su panel EFI y desactivar el arranque seguro. Según las necesidades de seguridad del usuario, esa opción puede no ser aceptable. Una mejor opción a corto plazo es eliminar el SBAT que Microsoft publicó el martes pasado. Esto significa que los usuarios seguirán recibiendo algunos de los beneficios del arranque seguro incluso si siguen siendo vulnerables a ataques que explotan CVE-2022-2601. Los pasos para esta solución se describen a continuación. aquí (gracias a manutheeng para referencia).
Los pasos específicos son:
1. Deshabilitar el arranque seguro
2. Inicie sesión en su usuario de Ubuntu y abra una terminal
3. Eliminar la política SBAT con:Código: Seleccionar todo
sudo mokutil –set-sbat-policy eliminar
4. Reinicie su PC y vuelva a iniciar sesión en Ubuntu para actualizar la política SBAT
5. Reinicie y vuelva a habilitar el arranque seguro en su BIOS.
El incidente es el último que pone de relieve el caos en el que se ha convertido Secure Boot (o posiblemente siempre lo fue). En los últimos 18 meses, los investigadores han descubierto al menos cuatro vulnerabilidades que puede ser explotado para completamente castrar el mecanismo de seguridad. El anterior instancia más reciente Fue el resultado de las claves de prueba utilizadas para autenticar el Arranque Seguro en aproximadamente 500 modelos de dispositivos. Las claves estaban marcadas de forma destacada con las palabras “NO CONFÍE”.
“Al final, si bien Secure Boot hace que el arranque de Windows sea más seguro, parece tener una cantidad cada vez mayor de fallas que lo hacen menos seguro de lo que se pretende”, dijo Will Dormann, analista de vulnerabilidades de la empresa de seguridad Analygence. “SecureBoot se complica porque no es un juego exclusivo de Microsoft, aunque ellos tienen las llaves del reino. Cualquier vulnerabilidad en un componente de SecureBoot podría afectar a un sistema exclusivo de Windows habilitado para SecureBoot. Por lo tanto, Microsoft tiene que abordar o bloquear las vulnerabilidades”.
