
PoC e informe de vulnerabilidad para CVE-2025-47827.
Prueba de concepto e informe de vulnerabilidad para CVE-2025-47827.
En IGEL OS anterior a v11, Secure Boot puede ser eludido porque el módulo
igel-flash-driver verifica incorrectamente una firma criptográfica.
En última instancia, se puede montar un sistema de archivos raíz manipulado desde
una imagen SquashFS no verificada.
La verificación incorrecta de la firma criptográfica en el módulo del kernel de Linux
igel-flash-driver en IGEL OS 10 permite que un actor malicioso eluda
Secure Boot, arrancando el shim firmado por Microsoft 3rd Party UEFI CA, que
luego carga GRUB y el kernel vulnerable, ambos firmados por IGEL Secure Boot
Signing CA. Una vez que se ha cargado el kernel vulnerable y el initramfs integrado,
se puede montar un sistema de archivos raíz malicioso desde la imagen SquashFS no verificada en el disco.
Como la llamada al sistema kexec_load está disponible en el kernel vulnerable, el kernel
actualmente arrancado puede ser reemplazado por uno completamente no confiable,
permitiendo prácticamente que cualquier sistema operativo arranque, siguiendo una cadena
completa de confianza.
En versiones posteriores de IGEL OS, el módulo verifica correctamente la firma de la imagen SquashFS del sistema de archivos raíz. Sin embargo, tanto el kernel vulnerable como las versiones parcheadas están firmados con el mismo certificado, lo que permite que el mismo shim arranque tanto versiones vulnerables como parcheadas.

La cadena vectorial inicial para CVE-2025-47827 fue
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
obteniendo una puntuación CVSS de 8.4 (alta).
El 14 de octubre de 2025, esto se cambió a
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
reduciendo la puntuación a 4.6 (media).
Además, la debilidad original se definió como CWE-347: Verificación incorrecta de firma criptográfica, pero MSRC le ha asignado CWE-324: Uso de una clave después de su fecha de expiración.
Tanto IGEL como Microsoft fueron contactados e informados sobre esta vulnerabilidad, el 6 de diciembre de 2024 y el 31 de marzo de 2025 respectivamente, antes de que los detalles se hicieran públicos el 29 de mayo de 2025.
Como IGEL OS 10 no tiene soporte y la vulnerabilidad no existe directamente en el shim, ninguna de las partes ha sugerido una solución. Microsoft respondió con lo siguiente:
Tras la investigación, hemos determinado que este envío no cumple con la definición de vulnerabilidad de seguridad para mantenimiento, ya que IGEL OS v10 ya no tiene soporte y el problema está en el módulo del kernel, no en el shim. Solo el shim está firmado por el certificado de MSFT.
IGEL publicó un aviso de seguridad para CVE-2025-47827 el 2 de junio de 2025.
El 13 de junio de 2025, reporté esto nuevamente a Microsoft y recibí la siguiente respuesta:
Aunque su informe incluía información útil, no cumple con el requisito de Microsoft como vulnerabilidad de seguridad para mantenimiento. El problema reportado está en el módulo del kernel y no en el shim, y solo el shim está firmado por el certificado de MSFT. kexec ya permite eludir Secure Boot por diseño (Ref: kexec Command Line in Linux - Linux Expert Better 2025).
Esto cumpliría con los criterios de mantenimiento de MSRC si el problema estuviera en un controlador/componente de arranque. Esta es una vulnerabilidad en el controlador del kernel de la distribución de Linux. Esto ocurre después de UEFI "ExitBootServices", lo que significa que no es una elusión de Secure Boot. El usuario solo tiene ejecución de código a nivel de SO, no de arranque.
Desde la publicación de varios artículos de noticias sobre esta vulnerabilidad, los mantenedores de shim se pusieron en contacto con Microsoft e IGEL para discutir una solución.
Después de que se alcanzó una solución, creé otro caso en MSRC el 20 de octubre de 2025, preguntando por la razón detrás de la demora en revocar estos shims, modificaciones a la cadena vectorial CVSS y CWE, y por qué su guía de actualización indicaba que la vulnerabilidad no se había divulgado públicamente. Recibí la siguiente respuesta:
La vulnerabilidad de IGEL que se corrigió no es una elusión de Secure Boot. Es una elusión de integridad del kernel específica de Linux y no afecta a Windows. Los shims de IGEL son antiguos y no admiten la nueva revocación basada en SBAT. Por lo tanto, Microsoft emitió las revocaciones para protegerse contra posibles exploits de otras vulnerabilidades que han sido protegidas por SBAT.
Jeffrey Sutherland, Principal Lead Program Manager, respondió en el PR para explicar que, debido a la falta de SBAT, los shims tuvieron que ser revocados por DBX, e IGEL solicitó tiempo adicional para evitar consecuencias no deseadas. También se disculparon por no mantener la comunicación entre el investigador y las partes involucradas, según lo requerido por Divulgación Coordinada de Vulnerabilidades.
Una explotación de elusión de Secure Boot podría llevar al desarrollo de un bootkit/rootkit a nivel de kernel no detectado, lo que a su vez conlleva múltiples implicaciones, como:
Sin revocación o intervención manual, Secure Boot ha quedado inutilizado en todas las máquinas que confían en Microsoft 3rd Party UEFI CA, que es el valor predeterminado para la mayoría de los dispositivos al momento de escribir esto.