Seis vulnerabilidades de U-Boot podrían permitir la ejecución de código antes del arranque en dispositivos integrados

Investigadores de seguridad han divulgado seis vulnerabilidades en U-Boot, el ampliamente utilizado cargador de arranque de código abierto presente en sistemas Linux integrados, controladoras de gestión de servidores empresariales, equipos de red, dispositivos industriales y de Internet de las cosas. Las vulnerabilidades afectan a la lógica de verificación de firmas FIT de U-Boot y podrían permitir a un atacante provocar bloqueos o, en algunos casos, ejecutar código antes de que comience la carga del sistema operativo.

Dado que U-Boot opera en una fase temprana del proceso de inicio, las debilidades en sus rutinas de validación pueden tener consecuencias graves. Si un atacante puede manipular la secuencia de arranque, podría eludir los controles de seguridad, alterar el comportamiento del firmware o instalar malware persistente difícil de detectar una vez que el sistema está en funcionamiento.

Qué pueden hacer las vulnerabilidades

Binarly, que informó de los problemas, indicó que las vulnerabilidades presentan una gravedad que va desde condiciones de denegación de servicio hasta la ejecución arbitraria de código durante la verificación del firmware. Cuatro de los fallos pueden provocar que los dispositivos afectados se bloqueen, mientras que otros dos podrían permitir la ejecución de código malicioso mientras U-Boot comprueba una imagen que no es de confianza.

• Un problema puede bloquear U-Boot y podría provocar la ejecución de código en determinadas condiciones.
• Un fallo de corrupción de memoria podría explotarse para ejecutar código arbitrario.
• Una lectura fuera de los límites puede provocar el bloqueo del cargador de arranque.
• Una desreferencia de puntero nulo también puede dejar el dispositivo fuera de servicio.
• Una validación incorrecta de datos almacenados externamente puede provocar un bloqueo.
• Un problema de recursión no acotada puede agotar la memoria de la pila e interrumpir el proceso de arranque.

Binarly afirmó que gran parte del código vulnerable está presente desde U-Boot 2013.07, lo que significa que el problema podría abarcar más de 50 versiones estables y numerosas bifurcaciones de proveedores posteriores.

Estado de los parches y exposición

La empresa informó de las vulnerabilidades a los responsables del mantenimiento de U-Boot y envió correcciones, que ya se han incorporado al proyecto original. Sin embargo, el impacto para los clientes dependerá de si los fabricantes de hardware integran esos cambios en sus propias compilaciones de firmware y publican actualizaciones.

Esto deja especialmente expuestos a los productos antiguos y sin soporte, sobre todo los dispositivos que ya no reciben mantenimiento del firmware. En sistemas con funciones de gestión remota, como las controladoras de gestión de la placa base, un atacante que ya haya obtenido acceso a la interfaz de gestión podría enviar una imagen de firmware manipulada sin necesidad de acceder físicamente al dispositivo.