Hace pocos dias el equipo de seguridad de Guix revelo la existencia de múltiples vulnerabilidades críticas (con CVEs pendientes de asignación) en el gestor de paquetes Guix, afectando primordialmente a la implementación de su comando interno guix substitute.

Este comando, que el proceso en segundo plano guix-daemon ejecuta automáticamente para descargar paquetes binarios precompilados y verificar sus firmas digitales, presenta fallas que pueden desembocar en la ejecución remota de código en el sistema de la víctima, otorgando al atacante los mismos privilegios que posee el proceso en segundo plano (incluyendo privilegios de root si está configurado así). La gravedad de la situación radica en que estas vulnerabilidades afectan a todos los sistemas, independientemente de los permisos con los que se ejecute el demonio, aunque el daño es significativamente mayor cuando se opera como superusuario.

El peligro de la extracción prematura y las rutas maliciosas

Para que un atacante explote remotamente este fallo, solo es necesario que el sistema intente descargar un paquete binario desde un servidor malicioso o bajo su control. El usuario ni siquiera tiene que configurar este servidor explícitamente, ya que la vulnerabilidad puede ser explotada mediante la opción de descubrimiento automático –discover o a través de un ataque de intermediario (Man-in-the-Middle).

De hecho, usar conexiones cifradas HTTPS no mitiga el ataque, ya que el atacante solo necesita un certificado válido para su propio dominio. A nivel local, el fallo también puede ser explotado si un usuario logra conectarse al socket Unix de guix-daemon, el cual suele estar disponible para todos los usuarios por defecto.

La raiz del problema se encuentra en el controlador restore-file, el cual se encarga de extraer el contenido del paquete sustituto. La falla consiste en que la extracción comienza mientras el archivo se está descargando, en lugar de esperar a que finalice la descarga y se verifique la firma del hash. Peor aún, el proceso de extracción no filtra adecuadamente los caracteres de salto de directorio (como . o ..) ni las barras inclinadas en los nombres de los archivos.

Al inyectar nombres de archivo maliciosos dentro de un paquete modificado, el atacante puede forzar a que la extracción sobrescriba o cree archivos en cualquier lugar del sistema donde el demonio tenga permisos de escritura. Esto podría permitir, por ejemplo, sobrescribir el archivo de contraseñas, inyectar scripts en .bashrc o agregar credenciales falsas en .ssh/authorized_keys.

Falsificación de servidores y exposición de datos locales

El equipo descubrió que la explotación era posible porque el procedimiento fetch-narinfos (que obtiene los metadatos de los paquetes) no verificaba los certificados del servidor, asumiendo que la firma digital de los metadatos garantizaba su integridad.

Sin embargo, la URL de descarga del archivo no estaba cubierta por esta firma criptográfica, permitiendo que un servidor malicioso falsificara la dirección de descarga para enviar un paquete alterado. Aunque este paquete fraudulento sería finalmente rechazado tras la verificación final, la extracción prematura de los archivos ya habría causado estragos en el sistema. Es crucial mencionar que este controlador vulnerable también es utilizado por otros comandos del ecosistema, como guix offload, guix archive –extract y guix challenge, lo que amplía la superficie de ataque.

Adicionalmente a esta falla crítica, se detectaron otros tres problemas de seguridad importantes:

• El primero es que fetch-narinfos no validaba si los metadatos recibidos correspondían realmente a los paquetes solicitados, permitiendo a un servidor malicioso suplantar versiones y forzar la instalación de software obsoleto o inseguro.
• El segundo problema radicaba en que se permitía el uso de esquemas URI file:// tanto en las direcciones de los servidores como dentro de los metadatos. Al seguir enlaces simbólicos sin restricciones, un atacante local podía engañar al demonio para leer la primera línea de archivos confidenciales o manipular comportamientos del sistema a través del pseudo-sistema de archivos /proc.
• Finalmente, una cuarta vulnerabilidad afectaba a guix pull y guix time-machine. Al no desinfectar la clave de caché derivada del nombre del canal durante la autenticación de repositorios, un atacante que controlara un archivo de canales podía forzar la creación o sobrescritura de archivos arbitrarios inyectando rutas.

Parches y medidas de mitigación

La solución a esta crisis ha requerido la validación de rutas en restore-file para prohibir entradas vacías o caracteres de salto de directorio, e imponiendo la creación de directorios temporales seguros durante la extracción antes de validar los hashes.

También se corrigió la validación cruzada en fetch-narinfos, se restringió severamente el uso de URIs file:// y se modificó la forma en que se calculan las claves de caché para los canales, utilizando ahora identificadores hexadecimales seguros en lugar de nombres directos.

Finalmente, se recomienda encarecidamente a todos los administradores actualizar sus sistemas de inmediato, reconfigurando y reiniciando el servicio guix-daemon. Como medida de mitigación temporal durante el proceso de actualización, es aconsejable pasar el parámetro –no-substitutes a los comandos de Guix para evitar la conexión a servidores comprometidos.

Si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

Artículo original