Seis vulnerabilidades en el ampliamente utilizado gestor de arranque U-Boot han sido descubiertas, las cuales podrían permitir a atacantes ejecutar código malicioso durante el arranque del dispositivo, posibilitando ataques sigilosos al firmware que comprometen las protecciones de seguridad e instalan malware persistente.
U-Boot es uno de los gestores de arranque de código abierto más usados del mundo y se encuentra en muchos dispositivos Linux embebidos, incluyendo controladores de gestión de base (BMC) de servidores empresariales, equipos de red, sistemas industriales, dispositivos IoT y otros aparatos.
Dado que U-Boot es responsable de cargar el sistema operativo, las vulnerabilidades en el gestor de arranque pueden permitir a los atacantes comprometer un dispositivo antes de que el sistema operativo y su software de seguridad tengan la oportunidad de iniciarse. Una de sus características de seguridad, conocida como Arranque Verificado, utiliza firmas criptográficas para garantizar que solo se carguen imágenes de firmware y sistema operativo firmadas por una clave de confianza durante el inicio.
En un informe publicado esta semana, la empresa de seguridad de firmware Binarly reveló seis vulnerabilidades en el código de verificación de firmas FIT (Flattened Image Tree) de U-Boot.
Reconociendo la naturaleza crítica de este componente, el equipo de investigación de Binarly decidió examinar más de cerca la funcionalidad central del proyecto U-Boot. Esta investigación reveló seis vulnerabilidades distintas, con un impacto que va desde denegación de servicio (DoS) hasta ejecución arbitraria de código durante la verificación de una imagen no confiable.
Según los investigadores, dos de los fallos pueden potencialmente llevar a la ejecución arbitraria de código durante la verificación del firmware, mientras que los otros cuatro pueden ser explotados para bloquear dispositivos vulnerables.
- BRLY-2026-037: fallo que puede causar un bloqueo de U-Boot al procesar una imagen maliciosa y, bajo ciertas condiciones, puede usarse para ejecución arbitraria de código.
- BRLY-2026-038: vulnerabilidad de corrupción de memoria que podría permitir a atacantes ejecutar código arbitrario durante la verificación de firmas.
- BRLY-2026-039: vulnerabilidad de lectura fuera de límites que puede bloquear dispositivos.
- BRLY-2026-040: desreferencia de puntero nulo que permite bloquear el gestor de arranque.
- BRLY-2026-041: validación incorrecta de datos de firmware almacenados externamente.
- BRLY-2026-042: fallo de recursión ilimitada que agota la memoria de pila.
Según Binarly, la mayor parte del código vulnerable existe desde la versión 2013.07 de U-Boot, lo que hace que los fallos afecten potencialmente a más de 50 versiones del proyecto, así como a proveedores que utilizaron el código vulnerable en su propio firmware.
Esto significa que potencialmente afectan a más de 50 versiones estables del proyecto U-Boot. Contando muchos forks de proveedores posteriores, estas vulnerabilidades tienen un impacto significativo en la industria.
Si se explotan con éxito, las vulnerabilidades de ejecución arbitraria de código podrían permitir a los atacantes ejecutar código durante las primeras etapas del proceso de arranque. Dado que esto ocurre antes de que se cargue el sistema operativo, los atacantes podrían potencialmente desactivar funciones de seguridad del firmware, modificar el proceso de arranque, instalar malware persistente en el firmware o llevar a cabo otras acciones maliciosas con altos niveles de acceso.
Binarly señala que explotar estas vulnerabilidades no siempre requiere acceso físico. En sistemas como los BMC que admiten actualizaciones remotas de firmware, un atacante que ya haya comprometido la interfaz de gestión podría cargar una imagen de firmware especialmente diseñada para explotar los fallos.
Binarly reportó las vulnerabilidades a los mantenedores de U-Boot y envió parches para los seis problemas, los cuales han sido aceptados en el repositorio principal del proyecto. Sin embargo, dado que U-Boot está integrado en el firmware por fabricantes de hardware individuales, las correcciones deben primero ser incorporadas en las actualizaciones de firmware de los proveedores antes de que puedan distribuirse a los clientes. Los dispositivos antiguos o no compatibles que ya no reciben actualizaciones de firmware podrían no ser parcheados nunca.
Deja una respuesta