La puerta trasera de xz detectada con NixOS y compilaciones reproducibles

• En marzo de 2024, se descubrió una puerta trasera en el software xz usado para descomprimir tarballs de código fuente en distribuciones de Linux.
• Esta puerta trasera fue insertada de forma encubierta durante 3 años por el mantenedor malicioso Jia Tan.
• El incidente tuvo un gran impacto porque permitía ejecución remota de código y era muy difícil de detectar.
• Fue descubierta por casualidad por Andres Freund, desarrollador de Postgres en Microsoft, mientras investigaba una degradación de rendimiento, evitando una gran catástrofe.

Cómo funciona el ataque

• La puerta trasera secuestra el programa ssh para permitir ejecución remota de código.
• Modifica la función RSA_public_decrypt para que, al iniciar sesión con una clave RSA específica, el atacante pueda ejecutar comandos arbitrarios.
• Está compuesta por dos componentes principales:
  1. Un script que instala un archivo objeto malicioso como parte del proceso de compilación de xz.
  2. Un procedimiento que engancha la función RSA_public_decrypt.

1. Script de instalación del archivo objeto malicioso

• El archivo objeto malicioso está oculto en un archivo de prueba del repositorio git de xz.
• La puerta trasera solo se activaba en los tarballs de lanzamiento proporcionados por el mantenedor.

2. Procedimiento de enganche de la función RSA_public_decrypt

• Usa la función ifunc de glibc para forzar la ejecución de código que se ejecuta durante el tiempo de carga dinámica.
• Cuando se ejecuta ssh, se cargan libsystemd y liblzma, y en ese proceso la puerta trasera ejecuta código arbitrario.

Cómo evitar un desastre como el de xz

• Para aumentar la confiabilidad del software de código abierto, hay que abordar tanto los problemas sociales como los técnicos.
• Es necesario mejorar los procesos de seguridad de la cadena de suministro de software.

Compilar software desde fuentes confiables

• El ataque fue efectivo porque muchas distribuciones compilaron xz usando los tarballs proporcionados por el mantenedor.
• Siempre que sea posible, hay que compilar el software desde la fuente más confiable.

Cuando la situación lo permite...

• NixOS es una distribución basada en un modelo de gestión de paquetes funcional, y cada paquete se expresa en Nix, un lenguaje de programación funcional.
• NixOS tiene la cultura de usar archivos fuente generados automáticamente en GitHub.

Construir confianza en tarballs de lanzamiento no confiables

• NixOS tuvo que usar los tarballs proporcionados por el mantenedor en la etapa de bootstrap.
• Para reforzar la seguridad de la cadena de suministro de software, hay que establecer ciertas medidas de protección.

1. Comparación de fuentes

• Es importante verificar si el tarball de código fuente usado por la distribución es idéntico al de GitHub.
• Sin embargo, a menudo ocurre que el tarball de lanzamiento difiere del código fuente, y eso no necesariamente es un problema.

2. Aprovechar la reproducibilidad bit a bit

• Las compilaciones reproducibles son una propiedad de los proyectos de software que producen artefactos idénticos cuando se compilan dos veces bajo las mismas condiciones.
• La reproducibilidad bit a bit permite construir confianza en tarballs proporcionados por mantenedores no confiables.

Conclusión

• El incidente de la puerta trasera de xz recuerda la importancia de la seguridad en la cadena de suministro del software de código abierto.
• Sistemas como NixOS pueden reforzar la seguridad mediante compilaciones reproducibles.

[GN⁺]

Opiniones de Hacker News

• NixOS y las compilaciones reproducibles no detectaron la puerta trasera de xz. NixOS distribuyó la compilación maliciosa de xz, pero no hubo problema porque no estaba dirigida a NixOS

  • Los desarrolladores de NixOS se sorprendieron al ver que la versión maliciosa de xz había sido distribuida a los usuarios cuando se reveló la puerta trasera
  • La teoría y la realidad son distintas, y la razón por la que xz fue posible no fue una vulnerabilidad técnica sino un problema del "mundo real". Cuesta reconocer que no se puede parchear el mundo real con software

• Parece que el autor solo se está enfocando en este incidente. El caso de Jiatan es un ejemplo aislado, y la defensa también puede fallar en otros escenarios

  • Como usuario de NixOS, creo que es muy probable que NixOS no hubiera podido detectarlo. Sin evidencia, sería ingenuo confiar en NixOS

• NixOS no viene al caso porque la puerta trasera de xz apuntaba a RedHat y Debian. Irónicamente, la puerta trasera fue descubierta por un empleado de Microsoft

• El artículo menciona que las distribuciones deberían obtener el código fuente directamente desde un VCS (por ejemplo, Github) en vez de usar los tarballs tradicionales de instalación

  • Sin embargo, un mantenedor malicioso podría agregar blobs binarios directamente al repositorio del código fuente
  • El autor sugiere confiar en Github como si verificara el código, pero en realidad Github no valida el código

• Si queremos enfocarnos en un incidente que NixOS sí podría haber evitado, deberíamos centrarnos en el caso de CrowdStrike. Si hubiera sido posible arrancar con la configuración de ayer, la mayoría de los problemas se habrían mitigado

• NixOS compila todo desde el código fuente, verifica criptográficamente que las fuentes usadas no hayan sido alteradas y tiene dependencias de versiones entre paquetes. Debian también tiene compilaciones reproducibles

  • El problema es que el sistema de compilación no eliminó los archivos objeto precompilados antes de compilar desde el código fuente. Si nadie revisa el código fuente, se puede introducir una puerta trasera, y ni NixOS ni ninguna otra distribución pueden impedirlo

• "Podría haberlo hecho" significa que no está demostrado, y en la práctica sí lo distribuyeron

• Un análisis explicativo excelente. El título es incorrecto y engañoso, aunque quizá sea "técnicamente correcto", en el mejor de los casos en el sentido de "con una puerta trasera"

  • Se enfatiza la necesidad y el uso de herramientas de gestión de compilaciones, y que hay que crear explícitamente un grafo de trazabilidad causal sobre cómo los archivos afectan a otros archivos durante el proceso de compilación, además de construir mecanismos para imponer ese grafo o reportar desviaciones respecto a uno anterior

• Si el PR de Jia Tan hubiera sido aprobado, los artefactos maliciosos podrían haber llegado fácilmente a un release de Github igual que al tarball. Cuesta entender que un release de Github sea una mitigación de seguridad

• Sobre el hecho de que el tarball de lanzamiento sea distinto del código fuente

  • Si el tarball proporcionado por el mantenedor fue generado honestamente a partir del código fuente original, cuesta entender por qué versiones distintas y similares serían un problema
  • Hay que hacer que el tarball generado pueda reproducirse desde el propio código fuente, no excluir nada, y hacer git add y commit. Incluso en ese caso habría que revisar el historial de commits, y como a simple vista parecía inofensivo, queda la duda de cómo podría verificarse
  • Si el tarball mantenido se genera desde el código fuente del propietario y no está en Github, eso sí es un problema

• Había más problemas que simplemente subir archivos de prueba envenenados, pero cuesta entender cómo Nix podría haber evitado esto

  • Si un proyecto conocido cambiara de líder, habría que revisar cuidadosamente los commits y comprobar quién es el líder

• Me pregunto si entendí mal el artículo o si se me escapó algo