Investigadores de la empresa de seguridad de firmware Binarly han descubierto seis nuevas fallas en U-Boot, un pequeño programa que inicia una variedad de hardware, incluidos enrutadores domésticos, cámaras inteligentes y chips de administración dentro de servidores de centros de datos.
Cuatro de los errores pueden bloquear tu dispositivo. Los otros dos podrían permitir a un atacante introducir una imagen maliciosa delante del gestor de arranque y ejecutar su propio código antes de que el dispositivo verifique que el software es genuino.
La última parte es la clave. El gestor de arranque se ejecuta antes que el sistema operativo, por lo que una falla aquí puede interrumpir cualquier funcionalidad cargada posteriormente. Los seis errores ocurren mientras U-Boot lee una imagen que no es de confianza antes de verificar su firma.
Lo que encontró el binario
U-Boot puede agrupar el kernel, el árbol de dispositivos, el disco RAM y otros componentes de arranque en un solo paquete, el FIT (árbol de imágenes planas), y verifica la firma digital de ese paquete antes de ceder el control.
Binarly buscó puntos débiles en el cheque y encontró seis. Según Binarly, la mayor parte del código vulnerable ha estado presente en U-Boot durante más de 50 versiones estables desde la v2013.07, y en muchos firmwares de proveedores integrados sobre U-Boot.
El error se rastrea como avisos binarios BRLY-2026-037 a BRLY-2026-042. Aún no se ha asignado el identificador CVE. Estos se dividen en dos grupos. Dos pueden ejecutar código y cuatro solo pueden fallar.
Dos son BRLY-2026-037 y BRLY-2026-038, los cuales rastrean un valor no verificado. U-Boot llama a fdt_get_name, que es una búsqueda de biblioteca de análisis de árbol de dispositivos prestado. Para imágenes con formato incorrecto, esa búsqueda devuelve un puntero nulo y una longitud negativa. U-Boot usa ambos sin marcar uno ni el otro.
Un error sigue a un puntero nulo a una copia de memoria, lo que provoca un desbordamiento del búfer de pila en los dispositivos donde está asignada la dirección 0. La otra es ingresar una longitud negativa en una aritmética de puntero que se mueve hacia atrás hasta que se sobrescribe la dirección del remitente guardada. La distribución adecuada de la memoria permite el control manual sobre el código proporcionado por el atacante.
Los otros cuatro simplemente bloquean el gestor de arranque. BRLY-2026-039 y BRLY-2026-041 se basan en tamaños o compensaciones controlados por el atacante para leer más allá del final de la imagen. BRLY-2026-040 elimina la referencia a un puntero nulo que el formato de imagen antiguo devuelve sin marcar. BRLY-2026-042 se queda sin pila. Esto se inicia con una imagen profundamente anidada que impulsa un paso de validación inicial que se llama a sí mismo hasta que se agota la pila.
Binarly publicó imágenes de prueba de concepto y pasos de reproducción para cada defecto y los demostró frente a una construcción estándar de U-Boot. No se han reportado exploits en ataques reales.
De los seis errores, se deben priorizar dos errores de corrupción de memoria. Una falla puede desconectar un dispositivo, pero ejecutar código al inicio puede romper toda la cadena de confianza.
¿Qué tan malo podría ser?
En el peor de los casos, recuperar un dispositivo que no arranca requiere acceso físico y actualizar sus chips de memoria con una imagen limpia. La ejecución del código es aún peor. El código que hace esto temprano se encuentra debajo del sistema operativo y puede no ser visible para las herramientas de seguridad normales.
La trampa para los atacantes es la distribución. Estos errores sólo aparecen si la imagen maliciosa llega a la ruta de inicio. Las rutas de arranque normalmente requieren acceso físico o un punto de apoyo privilegiado. Ese punto de apoyo no es necesariamente local.
En trabajos anteriores sobre los controladores de administración del servidor de Supermicro, los mismos investigadores de Binarly demostraron que un atacante con acceso remoto a la interfaz de administración podría explotar el propio proceso de actualización del dispositivo para mostrar una imagen maliciosa sin tocar el hardware.
que hacer
Los proveedores y mantenedores de productos basados en U-Boot no necesitan esperar, ya que aún no existe una versión estable que contenga esta solución. Dado que no hay CVE, siga el enlace de confirmación de cada aviso de Binarly para obtener la solución ascendente ahora y realizar un seguimiento por ID de aviso.
U-Boot fusionó seis parches en junio, pero la versión de julio (v2026.07) se envió sin parches porque ya estaba congelada en abril. La próxima versión v2026.10 no está prevista hasta octubre.
Otros ejecutan dispositivos que otra persona construyó sobre U-Boot. Para ellos, las correcciones deben llegar como actualizaciones de firmware de los proveedores de productos. A eso es a lo que debes prestarle atención.
Esta verificación exacta ha fallado antes. La misma lógica de firma fue atacada hace varios meses por CVE-2026-33243, y U-Boot la parchó en abril. Un gestor de arranque barebox relacionado que utiliza las mismas herramientas de imagen también fue un éxito.
En este error, una propiedad cuyo único propósito era enumerar lo que estaba firmado no estaba firmada, lo que permitía que una imagen manipulada reemplazara partes no verificadas. El asistente detrás de los dos peores errores aquí, fdt_get_name, proviene de libfdt, la biblioteca de árbol de dispositivos aplanada que U-Boot comparte con cosas como el kernel de Linux y barebox. El mismo error de devolución no verificado puede surgir dondequiera que se utilice ese código.
LogoFAIL, que THN cubrió en 2023, era un conjunto de errores de análisis de imágenes en el firmware de la PC que permitían ejecutar el código del atacante antes de verificar qué era el arranque seguro durante el arranque, en casi todas las principales marcas de PC. Las firmas llaman la atención. Los insectos seguirán invadiendo las tuberías que se encuentran delante.
Y como demostró BootHole en 2020, cuando una única falla del gestor de arranque rompe el arranque seguro de todo un ecosistema, crear un parche es la parte fácil. Lo que es lento es incorporarlo a millones de dispositivos que ejecutan la copia U-Boot de otra persona.
Source link
