Getty Images El martes pasado, muchos usuarios de Linux (muchos de ellos con paquetes lanzados este año) empezaron a informar que sus dispositivos no arrancaban. En cambio, recibieron un mensaje de error críptico que incluía la frase: «Algo ha ido muy mal». La causa: una actualización que Microsoft publicó como parte de su lanzamiento mensual de parches. Su objetivo era cerrar una vulnerabilidad de hace 2 años en GRUB, un cargador de arranque de código abierto utilizado para iniciar muchos dispositivos Linux. La vulnerabilidad, con una calificación de gravedad de 8,6 sobre 10, hizo posible que los piratas informáticos eludieran 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 lo parcheó el martes pasado. Varias distribuciones, tanto nuevas como antiguas, afectadas por la actualización del martes dejaron a los dispositivos de arranque dual (es decir, aquellos configurados para ejecutar Windows y Linux) sin poder arrancar en este último cuando se aplicó el arranque seguro. Cuando los usuarios intentaron cargar Linux, recibieron el mensaje: “Error al verificar los datos de shim SBAT: Violación de la política de seguridad. Algo salió muy mal: Falló la autocomprobación de SBAT: Violación de la política de seguridad”. Casi de inmediato, los foros de soporte y discusión se llenaron de informes del error. “Tenga en cuenta que Windows dice que esta actualización no se aplicará a los sistemas que arrancan Windows y Linux de forma dual”, escribió una persona frustrada. “Obviamente, esto no es cierto y probablemente depende de la configuración de su sistema y de la distribución que se esté ejecutando. Parece haber hecho que algunos cargadores de arranque shim de Linux sean incompatibles con los cargadores de arranque efi microcrap (por eso funciona cambiar de MS efi a ‘otro SO’ en la configuración de efi). Parece que Mint tiene una versión de shim que MS SBAT no reconoce”. Los informes indican que varias distribuciones, incluidas Debian, Ubuntu, Linux Mint, Zorin OS, Puppy Linux, están afectadas. Microsoft aún no ha reconocido el error públicamente, 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 compañía no respondieron a un correo electrónico en el que se solicitaban respuestas. El boletín de Microsoft para CVE-20220-2601 explicaba 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, trabaje con su proveedor de Linux para obtener una actualización». De hecho, la actualización se ha aplicado a dispositivos que arrancan tanto Windows como Linux. Eso no solo incluye dispositivos de arranque dual, sino también dispositivos Windows que pueden arrancar Linux desde una imagen ISO, una 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é? Con Microsoft manteniendo el silencio de radio, los afectados por la falla se han visto obligados a encontrar sus propios remedios. Una opción es acceder a su panel EFI y desactivar el arranque seguro. Dependiendo de 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 lanzó el martes pasado. Esto significa que los usuarios seguirán recibiendo algunos de los beneficios del Arranque Seguro incluso si siguen siendo vulnerables a los ataques que explotan CVE-2022-2601. Los pasos para esta solución se describen aquí (gracias a manutheeng por la referencia). Los pasos específicos son: 1. Deshabilitar el Arranque Seguro2. Inicia sesión con tu usuario de Ubuntu y abre una terminal3. Elimina la política SBAT con: Código: Select all sudo mokutil –set-sbat-policy delete 4. Reinicia tu PC y vuelve a iniciar sesión en Ubuntu para actualizar la política SBAT5. Reinicie y vuelva a habilitar el arranque seguro en su BIOS. Este incidente es el último que pone de relieve el caos en el que se ha convertido Secure Boot, o posiblemente siempre lo fue. Durante los últimos 18 meses, los investigadores han descubierto al menos cuatro vulnerabilidades que pueden explotarse para neutralizar por completo el mecanismo de seguridad. El caso más reciente anterior fue el resultado de las claves de prueba utilizadas para autenticar Secure Boot en aproximadamente 500 modelos de dispositivos. Las claves estaban marcadas de forma destacada con las palabras «NO CONFÍE». «Al final del día, si bien Secure Boot hace que el arranque de Windows sea más seguro, parece tener una pila creciente de fallas que lo hacen no tan seguro como se pretende que sea», dijo Will Dormann, un analista de vulnerabilidades senior en la empresa de seguridad Analygence. «SecureBoot se vuelve complicado en el sentido de que no es un juego exclusivo de MS, aunque tienen las llaves del reino. Cualquier vulnerabilidad en un componente de SecureBoot podría afectar a un sistema exclusivo de Windows habilitado con SecureBoot. Como tal, MS tiene que abordar/bloquear las cosas vulnerables».