Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco Cisco Talos (la división de investigación y desarrollo de ciberseguridad de de Cisco Systems) dio a conocer, mediante una publicación de blog, información sobre el descubrimiento de una serie de vulnerabilidades en el sistema de compilación Buildroot.

Cisco Talos menciono el descubrimiento de seis vulnerabilidades en Buildroot que permiten, durante la interceptación del tráfico de tránsito (MITM), realizar cambios en las imágenes del sistema generadas u organizar la ejecución del código en el sistema de compilación.

Las primeras cinco vulnerabilidades catalogadas bajo TALOS-2023-1844 (CVE-2023-45841, CVE-2023-45842, CVE-2023-45838, CVE-2023-45839, CVE-2023-45840) afectan el código para verificar la integridad de los paquetes mediante hashes.

Los problemas se reducen a la capacidad de usar HTTP para descargar archivos y la falta de archivos hash de verificación para algunos paquetes, lo que permite reemplazar el contenido de estos paquetes, teniendo la oportunidad de interferir en el tráfico del servidor de compilación (por ejemplo cuando un usuario se conecta a través de una red inalámbrica controlada por un atacante).

Debido a que los paquetes pueden incluir archivos de parche o Makefiles, al proporcionar un paquete fuente comprometido, un atacante podría ejecutar comandos arbitrarios en el compilador. Como consecuencia directa, un atacante también podría alterar cualquier archivo generado para los objetivos y hosts de Buildroot.

En particular, los paquetes aufs y aufs-util se cargaron a través de HTTP y no se compararon con hashes. También faltaban hashes para los paquetes riscv64-elf-toolchain, versal-firmware y mxsldr, que se cargaban a través de HTTPS de forma predeterminada, pero recurrían a descargas no cifradas en caso de problemas. Si no había archivos «.hash», la herramienta Buildroot consideró que la verificación fue exitosa y procesó los paquetes descargados, incluida la aplicación de los parches incluidos en los paquetes y la ejecución de scripts de compilación.

Al tener la capacidad de falsificar paquetes descargados, el atacante podía agregarles sus propios parches o Makefiles, lo que permitía realizar cambios en la imagen resultante o crear scripts del sistema y lograr la ejecución de su código.

Por la parte de la sexta vulnerabilidad que fue catalogada bajo TALOS-2023-1845 (CVE-2023-43608) es causada por un error en la implementación de la funcionalidad BR_NO_CHECK_HASH_FOR, que permite deshabilitar las comprobaciones de integridad hash para paquetes seleccionados.

Se menciona que para:

Cada línea hash del archivo .hash, check_one_hash se denomina. Si hash no coincide, check_one_hash saldrá con un código de error. De lo contrario, nb_checks se incrementa para indicar una verificación exitosa. Si no hay ninguna entrada en el archivo .hash para verificar el archivo de entrada especificado, la verificación en la condicion IF devolverá un error a menos que BR_NO_CHECK_HASH_FOR[9] contenga este archivo específico, lo que significa que el archivo está excluido de las comprobaciones de hash.

En total, hay 3 formas de check-hash devuelva el valor 0:

1. .hash no existe ningún archivo para el paquete
2. $file hash coincide con la definición del archivo .hash
3. $file no está presente en el archivo .hash y BR_NO_CHECK_HASH_FOR contiene el nombre base del paquete (omitiendo explícitamente las comprobaciones)

Para el concepto de demostración de la vulnerabilidad, los desarrolladores se centraron en la opción 3, ya que parece que esto parece usarse comúnmente para omitir las comprobaciones de integridad de recursos que no se pueden aplicar hash fácilmente (por ejemplo, recursos de desarrollo que cambian con frecuencia). También se utiliza al crear versiones específicas de un paquete, para las cuales los hashes pueden no estar disponibles en las fuentes de Buildroot.

Algunos paquetes, como el kernel de Linux, U-Boot y versal-firmware, permitían cargar las últimas versiones para las cuales aún no se habían generado hashes de verificación. Para estas versiones se utilizó la opción BR_NO_CHECK_HASH_FOR, que deshabilita la verificación de hash.

Los datos se descargaron a través de HTTPS, pero de forma predeterminada, si la descarga fallaba, se utilizaba una alternativa para acceder al sitio sin cifrado utilizando el protocolo http://. Durante un ataque MITM, un atacante podría bloquear la conexión al servidor HTTPS y luego la descarga se revierte.

Finalmente, cabe mencionar que las vulnerabilidades se resuelven en las últimas versiones Buildroot y si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.