Los UEFI shims olvidados que socavan Secure Boot
Investigadores de ESET encontraron 11 shim bootloaders UEFI firmados por Microsoft con vulnerabilidades de hasta 10 años que permiten eludir Secure Boot. Un riesgo silencioso para millones de PCs.
Un informe reciente de ESET volvió a poner el foco en un problema que la industria parecía haber olvidado: los shim bootloaders UEFI firmados por Microsoft que siguen siendo vulnerables.
Los investigadores identificaron 11 shims diferentes que contienen fallas conocidas desde hace hasta una década. Estas vulnerabilidades permiten a un atacante con acceso físico eludir UEFI Secure Boot, mecanismo diseñado precisamente para impedir la ejecución de código no autorizado durante el arranque.
¿Qué es un shim y por qué Microsoft lo firma?
El shim es un bootloader de primera etapa desarrollado originalmente para permitir que distribuciones Linux (como Fedora, Ubuntu o SUSE) arranquen en sistemas con Secure Boot activado. Como Microsoft es quien mantiene la base de datos de claves de confianza en la mayoría de los PCs, tiene que firmar digitalmente estos shims para que sean aceptados por el firmware.
El problema surge cuando esos shims, una vez firmados, nunca más se actualizan o se dejan olvidados en repositorios y distribuciones antiguas. Un atacante que obtenga uno de estos shims vulnerables puede usarlo para cargar código arbitrario y desactivar Secure Boot sin que el sistema lo rechace.
Las vulnerabilidades detectadas
Según el reporte, varias de las fallas datan de 2013-2016 y afectan a shims utilizados por diferentes fabricantes y proyectos open source. Entre las más graves se encuentran desbordamientos de búfer y validaciones insuficientes de archivos PE que permiten ejecutar código en modo kernel antes de que el sistema operativo cargue.
Lo más preocupante es que estos shims siguen apareciendo en imágenes de instalación, medios de recuperación y hasta en algunos dispositivos embebidos o industriales que no reciben actualizaciones frecuentes de firmware.
Impacto real y quiénes están expuestos
Cualquier equipo con Secure Boot activado que use (o haya usado) una distribución Linux que incluya estos shims está potencialmente expuesto. Aunque el ataque requiere acceso físico, en escenarios de robo de laptops corporativas, reacondicionamiento de equipos o cadenas de suministro comprometidas, el riesgo es concreto.
Además, una vez que Secure Boot es eludido, el atacante puede instalar bootkits persistentes que sobreviven incluso a reinstalaciones del sistema operativo.
¿Qué deberías hacer como administrador o usuario avanzado?
- Verificar la versión del shim instalado en tu equipo (en la mayoría de las distribuciones Linux se encuentra en
/boot/efi/EFI/*/shim*.efi). - Actualizar a las versiones más recientes proporcionadas por tu distribución. Canonical, Red Hat y SUSE ya publicaron parches.
- Revisar si tu firmware UEFI recibe actualizaciones regulares y aplicarlas.
- Considerar el uso de Measured Boot o TPM 2.0 para agregar una capa adicional de verificación.
- En entornos corporativos, implementar políticas que bloqueen el uso de medios de arranque externos no autorizados.
Microsoft ya revocó varias de las claves comprometidas, pero el proceso de propagación de esa revocación es lento y depende de que los fabricantes actualicen las bases de datos de firmware.
Conclusión
Este hallazgo vuelve a demostrar que Secure Boot no es una solución mágica y que su seguridad depende de la higiene de todo el ecosistema: desde Microsoft hasta los mantenedores de distribuciones y los fabricantes de hardware. Dejar shims firmados y olvidados en la cadena de confianza es, básicamente, dejar una puerta trasera abierta durante años.
Si administrás servidores, workstations o simplemente querés dormir tranquilo, es momento de revisar qué shim tenés cargando en tu equipo antes del kernel.
