- Durante más de 2 años, un atacante que usaba el nombre "Jia Tan" actuó como un colaborador diligente y eficaz de la biblioteca de compresión xz, hasta que finalmente recibió permisos de commit y privilegios de administrador.
- Usó esos privilegios para instalar una puerta trasera muy sutil y cuidadosamente oculta en liblzma, parte de xz, que también es una dependencia de OpenSSH
sshd en Debian, Ubuntu, Fedora y otros sistemas Linux basados en systemd.
- Esta puerta trasera vigilaba el inicio de sesiones SSH para detectar el envío de comandos ocultos por parte del atacante, dándole la capacidad de ejecutar comandos arbitrarios en el sistema objetivo sin necesidad de iniciar sesión. Es una ejecución remota de código no autenticada contra el objetivo.
- Este ataque se reveló públicamente el 29 de marzo de 2024 y parece ser el primer ataque grave a la cadena de suministro contra software open source de uso extendido.
- Es un hecho que marcará un antes y un después en la seguridad de la cadena de suministro del open source.
- Esta publicación es una cronología detallada de los aspectos de ingeniería social de este ataque, que aparentemente se remontan a finales de 2021.
Preludio
- 2005-2008: Lasse Collin, con ayuda de otras personas, diseñó el formato de archivo
.xz usando el algoritmo de compresión LZMA, que comprime archivos hasta aproximadamente el 70% del tamaño logrado por gzip.
- Con el tiempo, este formato pasó a usarse ampliamente para comprimir archivos tar, imágenes del kernel de Linux y más.
La aparición de Jia Tan y sus apoyos
- 2021-10-29: Jia Tan envía su primer parche inocuo a la lista de correo
xz-devel.
- 2021-11-29: Jia Tan envía un segundo parche inocuo.
- 2022-04-19: Jia Tan envía otro parche inocuo.
- 2022-04-22: "Jigar Kumar" se queja de que el parche de Jia Tan aún no ha sido integrado.
- 2022-05-19: "Dennis Ens" pregunta por el estado de mantenimiento de XZ for Java.
- 2022-05-19: Lasse Collin se disculpa por la lentitud de sus respuestas y responde que "Jia Tan me está ayudando con XZ Utils fuera de la lista, y al menos podría asumir un rol más importante en XZ Utils".
- 2022-05-27: Jigar Kumar envía un correo de presión al hilo del parche.
- 2022-06-07: Jigar Kumar envía un correo de presión al hilo de Java.
- 2022-06-08: Lasse Collin responde que no ha perdido el interés, pero que está limitado por problemas de salud mental.
- 2022-06-10: Lasse Collin integra el primer commit escrito por Jia Tan.
- 2022-06-14: Jugar Kumar envía otro correo de presión.
- 2022-06-21: Dennis Ens envía un correo de presión sugiriendo transferir el mantenimiento a otra persona.
- 2022-06-22: Jigar Kumar envía un correo de presión al hilo del parche en C.
- 2022-06-29: Lasse Collin responde dando a entender que "Jia Tan podría asumir un rol más grande en el proyecto".
Jia Tan se convierte en mantenedor
- Lasse parece haber comenzado a colaborar más estrechamente con Jia Tan. Es muy probable que Jigar Kumar y Dennis Ens fueran identidades falsas.
- 2022-09-27: Jia Tan entrega un resumen del lanzamiento 5.4.0.
- 2022-11-30: Lasse Collin cambia los correos de reportes de bugs desde su dirección personal a un alias compartido con Jia Tan.
- 2022-12-30: Jia Tan integra directamente su primer commit en el repositorio de xz.
- 2023-01-11: Lasse Collin etiqueta y compila v5.4.1, su último lanzamiento.
- 2023-03-18: Jia Tan etiqueta y compila v5.4.2, su primer lanzamiento.
- 2023-03-20: Jia Tan actualiza la configuración de Google
oss-fuzz para que los bugs le lleguen a él.
- 2023-06-22: Hans Jansen envía un par de parches que usan la función "GNU indirect function"; Lasse Collin los retrabaja y Jia Tan los integra.
- 2023-07-07: Jia Tan desactiva el soporte de
ifunc durante las compilaciones de oss-fuzz.
- 2024-01-19: Jia Tan mueve el sitio web a GitHub Pages y toma control de la página web de XZ Utils.
Inicio del ataque
- 2024-02-23: Jia Tan integra código binario de la puerta trasera oculto dentro de archivos de entrada de prueba.
- 2024-02-24: Jia Tan etiqueta v5.6.0 y publica la distribución
xz-5.6.0.tar.gz, que incluye el malicioso build-to-host.m4.
- 2024-02-24: En Gentoo empiezan a producirse fallos con 5.6.0.
- 2024-02-26: Debian agrega
xz-utils 5.6.0-0.1 a unstable.
- 2024-02-28: Debian agrega
xz-utils 5.6.0-0.2 a unstable.
- 2024-02-29: En GitHub,
@teknoraver envía un pull request para evitar que liblzma se enlace con libsystemd.
- 2024-02-28: Jia Tan introduce un typo sutil en el programa en C usado para verificar soporte de Landlock, rompiendo así su detección en el script
configure.
- 2024-03-04: En distribuciones de RedHat empiezan a aparecer errores de Valgrind en
_get_cpuid de liblzma.
- 2024-03-05: Se integra el PR de
libsystemd y se elimina liblzma.
- 2024-03-05: Debian agrega
xz-utils 5.6.0-0.2 a testing.
- 2024-03-05: Jia Tan hace commit de una corrección de bug de
ifunc.
- 2024-03-08: Jia Tan hace un commit para una corrección de Valgrind.
- 2024-03-09: Jia Tan hace un commit actualizando los archivos de la puerta trasera.
- 2024-03-09: Jia Tan etiqueta v5.6.1 y publica la distribución de xz 5.6.1.
- 2024-03-20: Lasse Collin envía a LKML un conjunto de parches para agregarse a sí mismo y a Jia Tan como mantenedores del código de compresión xz del kernel.
- 2024-03-25: Hans Jansen reporta un bug en Debian para actualizar
xz-utils a 5.6.1.
- 2024-03-28: Jia Tan reporta un bug en Ubuntu para que
xz-utils se actualice a 5.6.1 desde Debian.
Detección del ataque
- 2024-03-28: Andres Freund descubre el bug y avisa en privado a Debian y a
distros@openwall. RedHat asigna CVE-2024-3094.
- 2024-03-28: Debian revierte 5.6.1 e introduce
5.6.1+really5.4.5-1.
- 2024-03-29: Andres Freund publica una alerta sobre la puerta trasera en la lista pública
oss-security@openwall, diciendo que la descubrió "durante las últimas semanas".
- 2024-03-29: RedHat anuncia que se distribuyó xz con la puerta trasera en Fedora Rawhide y Fedora Linux 40 beta.
- 2024-03-30: Debian detiene compilaciones y reconstruye máquinas de build usando Debian stable.
Opinión de GN⁺
- Este incidente será un punto de inflexión importante respecto a los ataques a la cadena de suministro en software open source. Esto se debe a que, mediante un enfoque de ingeniería social de largo plazo por parte de un conspirador, se ganó confianza y acceso, y luego se instaló sigilosamente una puerta trasera en una biblioteca central de uso amplio.
- Es necesario replantear los procesos de gobernanza y transferencia de privilegios en proyectos open source. Vale la pena considerar modelos de gobernanza distribuidos para que la situación personal de un mantenedor clave no determine el rumbo del proyecto.
- Las auditorías de seguridad y las revisiones de código en proyectos open source importantes serán aún más críticas. También hacen falta herramientas automatizadas de verificación para detectar cambios sospechosos y evitar abusos de privilegios; por ejemplo, alertas ante la adición de datos binarios.
- Sin perjudicar las ventajas del modelo open source, donde el desarrollo es público y cualquiera puede contribuir, deben prepararse medidas técnicas e institucionales que permitan filtrar a colaboradores maliciosos y bloquear ataques de forma temprana.
- Cuanto más dependa un proyecto open source de lenguajes o herramientas con debilidades de seguridad, mayor será el riesgo. Además de esfuerzos en múltiples frentes para reforzar la seguridad —como memory safety, análisis estático y fuzzing— también se exigirá una transición hacia herramientas modernas.
- Habrá gran interés en análisis detallados sobre las condiciones ocultas de activación de la puerta trasera, su ruta de propagación y el alcance de su impacto. Eso podría ofrecer lecciones útiles para defenderse de ataques similares en el futuro.
7 comentarios
Lo que me preocupa a raíz de este incidente es que... se hackee la PC de un desarrollador de open source, o lo secuestren/retengan, o lo compren con dinero para insertar código malicioso... Y al pensar en el dinero, también me pregunto si los desarrolladores de open source realmente estarán viviendo bien.
Trabajo en el área de seguridad, y cuando encuentro un bug haciendo code review, salen bromas como: “¿Entraste a trabajar aquí hace 5 años solo para meter este código?” jajaja
Parece que Lesser Collin la pasó bastante mal en muchos sentidos...
Sí, Arch Linux ya lo parcheó hace rato~ vengan, vengan. Sí, backdoor out, latest Arch es lo máximo~
pacman -SyuParece que Lasse Collin dejó un texto donde organiza todo este incidente
https://tukaani.org/xz-backdoor/
Opiniones de Hacker News
Excelente resumen del incidente, con todos los enlaces reunidos en un solo lugar; es un recurso perfecto para quienes quieren aprender cómo se desarrolla en la práctica un ataque de ingeniería social.
Señalan que falta la línea de tiempo de Fedora.
Se plantea que ya no deberíamos tolerar código difícil de entender dentro del sistema.
Esto parece ser uno de los posibles resultados positivos: una actitud más conservadora frente a las actualizaciones.
Se sugiere que en la comunidad FOSS podría haber un cambio cultural: vetar sistemáticamente a los usuarios groseros o aumentar la conciencia comunitaria para responder con más firmeza a ese tipo de comportamiento.
Se indica que la observación sobre el formato de las direcciones de correo electrónico es incorrecta.
Expresan preocupación por lo fácil que es que la presión social lleve a las personas a ceder el control.
Como mantenedor, se enfatiza que cuanto más insistan contribuyentes o usuarios con una petición, menos probable es que se les conceda.
Se cita la opinión de Joe Cooper y se comparte su postura sobre la presión ejercida sobre los mantenedores de proyectos.
Se explica que el código binario oculto de la puerta trasera estaba muy bien escondido dentro de archivos binarios de entrada de prueba, y como esos archivos fueron creados en su mayoría a mano con un editor hexadecimal, los propios archivos son el mejor "código fuente".