Brecha en XZ: una demostración de la seguridad del software libre

1 La librería XZ: Un compresor de datos libre, potente y versátil.

Anteriormente conocida como LZMA Utils, la librería XZ es una biblioteca de software libre y código abierto que provee un conjunto de utilidades de línea de comandos para comprimir y descomprimir datos sin pérdida. Se basa en el algoritmo de compresión Lempel-Ziv-Markov chain (LZMA), que ofrece una alta tasa de compresión y un buen equilibrio entre velocidad de compresión, velocidad de descompresión, eficacia en compresión sin pérdida y tasa de compresión (tamaño del resultado Vs tamaño original).

1.a Cómo se utiliza la librería

Se utiliza en una amplia variedad de aplicaciones, incluyendo:

• Compresión de archivos: Para comprimir archivos individuales o directorios enteros, reduciendo su tamaño y ahorrando espacio de almacenamiento.

• Empaquetado de software: Para empaquetar software y distribuciones de Linux, ya que permite crear archivos compactos y eficientes.

• Compresión de flujos de datos: Por su velocidad es preferida para comprimir flujos de datos en tiempo real, lo que la hace ideal para aplicaciones de red y transmisión de datos.

• Integración con otros sistemas: Como bases de datos y sistemas de archivos, para proporcionar compresión transparente de datos.

Todo ésto se logra gracias al uso del algoritmo LZMA, un algoritmo de compresión sin pérdida que se basa en la identificación y el reemplazo de patrones repetitivos en los datos que aprovecha un diccionario de patrones y un modelo estadístico para optimizar la compresión.

Dada la última característica mencionada “Integración con otros sistemas”, hay centenares de sistemas de información y software, en Linux, UNIX y MacOS que utilizan la librería XZ para solventar sus requerimientos de compresión, tanto para almacenamiento de datos como para transmisión de ellos, es más, el propio kernel del sistema operativo que se ejecuta al iniciar un dispositivo generalmente está comprimido con XZ. Google, Oracle, IBM y muchas otras megacorporaciones utilizan la librería XZ en sus proyectos. Proyectos como 1password, un administrador de constraseñas, utilizan XZ.

1.b Ejemplos de uso de la librería XZ en línea de comandos:

• Para comprimir un archivo llamado archivo.txt, puede utilizar el siguiente comando:
  xz archivo.txt

• Para descomprimir un archivo llamado archivo.txt.xz, puede utilizar el siguiente comando:
  unxz archivo.txt.xz

• Para empaquetar y comprimir una carpeta llamada directorio, puede utilizar el siguiente comando:
  tar Jcvf directorio.tar.xz directorio

• Para descomprimir y desempaquetar un archivo comprimido llamado directorio.tar.xz, puede utilizar el siguiente comando:
  tar Jxvf directorio.tar.xz

• En forma análoga si se desea utilizar el algoritmo lzma:

  • lzma archivo.txt

  • unlzma archivo.txt.lzma

  • tar Ycvf directorio.tar.lzma directorio

  • tar Yxvf directorio.tar.lzma

2 ¿Es suficiente la libertad para garantizar la calidad?

La respuesta corta es que la libertad en el software no es garantía de seguridad ni calidad.

El software libre, a pesar de sus innegables beneficios, no está exento de riesgos. La idea de que la libertad del software implica automáticamente su seguridad y calidad es un error común. Al igual que en el software privado o privativo, existe software malo e inseguro así como bueno y seguro.

Las licencias de software libre no garantizan la seguridad ni la calidad. Su función principal es proteger o restringir las libertades de los usuarios, como la libertad de usar, modificar y distribuir el software. Si bien algunas licencias, como la GPL, incluyen cláusulas que fomentan la colaboración y la transparencia, estas no son garantías de que el software sea seguro o de alta calidad.

2.a Entonces ¿cómo se verifica la seguridad del software libre?

Para evaluar la seguridad y calidad del software libre, existen dos métodos principales:

Análisis del código fuente:

Este método implica descargar el código fuente del software y revisarlo línea por línea para identificar posibles vulnerabilidades o problemas de seguridad. Si bien es un método efectivo, es extremadamente costoso en tiempo y recursos, y requiere un alto nivel de conocimiento técnico.

Gobiernos y megacorporaciones, como el gobierno ruso con Astra Linux y Novell con SuSE, han invertido en este tipo de análisis para certificar la seguridad de sus distribuciones de Linux. Sin embargo, este enfoque no es viable para la mayoría de los usuarios individuales o pequeños proyectos de software libre.

Análisis de la comunidad:

Este método se basa en la idea de que un software libre con una comunidad activa y comprometida tiene mayor probabilidad de ser seguro y de alta calidad. Los indicadores clave a considerar son:

• Tamaño y actividad de la comunidad: Un software con una comunidad grande y activa indica mayor interés y participación en su desarrollo, lo que aumenta las probabilidades de detectar y corregir errores o vulnerabilidades.

• Foros de discusión y canales de comunicación: La existencia de foros de discusión activos y canales de comunicación donde los usuarios pueden interactuar con los desarrolladores y entre sí es un indicio de una comunidad comprometida.

• Frecuencia de actualizaciones y nuevas versiones: Un software con un ritmo constante de actualizaciones y nuevas versiones demuestra que los desarrolladores están trabajando activamente en su mejora y mantenimiento.

• Documentación completa y actualizada: La disponibilidad de documentación generosa, actualizada y traducida a varios idiomas facilita el uso del software y aumenta la probabilidad de que los usuarios detecten y reporten problemas.

Si bien este método no ofrece una garantía absoluta de seguridad y calidad, es más accesible y práctico para la mayoría de los usuarios. Permite evaluar el nivel de compromiso de la comunidad y la probabilidad de que el software se mantenga actualizado y libre de errores graves.

Es fundamental evaluar cada proyecto de software libre de forma individual, considerando tanto el análisis del código fuente como la evaluación de la comunidad. La combinación de estos dos métodos permite tomar decisiones informadas sobre la seguridad y calidad del software libre que se utiliza.

3 Una paradoja de la seguridad en el software libre

En el mundo del software libre, la seguridad siempre ha sido un tema de debate acalorado. Los detractores del software libre suelen señalar la falta de un control centralizado como un punto débil, mientras que sus defensores argumentan que la transparencia y la colaboración inherentes a este modelo lo convierten en un entorno más seguro. La reciente brecha de seguridad en la librería XZ, utilizada para comprimir datos en prácticamente toda la infraestructura digital moderna, ha reavivado este debate con ímpetu renovado.

Para comprender el funcionamiento de la seguridad del software libre, hay que imaginar una puerta con su chapa totalmente transparentes. Cualquier persona podría ver el mecanismo de la chapa, pero sin la llave correspondiente no podrá abrir la puerta. También es cierto que expertos cerrajeros podrán identificar y advertir las vulnerabilidades que tiene el mecanismo y podrán utilizar su conocimiento tanto para violentarla como para corregirla. Con una gran ventaja, cuando se corrige cualquier vulnerabilidad, todas las puertas quedan automáticamente mejoradas sin ningún costo para el dueño.

La vulnerabilidad en XZ, que permitía a un atacante ejecutar código arbitrario en cualquier sistema que utilizara la librería, puso de manifiesto la fragilidad incluso de los proyectos de software libre más populares y ampliamente utilizados. Sin embargo, esta brecha también ilustra la paradoja de la seguridad en el software libre: la apertura y la transparencia que caracterizan a este modelo, si bien pueden ser explotadas por actores maliciosos, también son la clave para su robustez y protección.

Como bien dijo el legendario hacker y filósofo del software libre, Eric Raymond: "a mayor cantidad de ojos, más rápido se detectan los errores". La naturaleza descentralizada del software libre permite que una gran cantidad de desarrolladores y usuarios examinen el código fuente, lo que aumenta significativamente las posibilidades de identificar y corregir vulnerabilidades antes de que puedan causar daños generalizados.

4 Un líder agotado

Lasse Collin es un ingeniero de software finlandés, quien vive en Nebraska USA, conocido principalmente por ser el principal mantenedor de la biblioteca XZ. Ha sido un contribuyente activo al proyecto XZ desde 2002 y ha desempeñado un papel fundamental en su desarrollo y mantenimiento.

Las razones exactas por las que Lasse Collin buscaba delegar su rol como mantenedor principal de XZ no son públicas. Sin embargo, existen algunas pistas que sugieren que el agotamiento, problemas de salud y la sobrecarga de trabajo podrían haber sido factores importantes.

• Mantenimiento a largo plazo: Lasse Collin ha estado involucrado en el proyecto XZ durante más de dos décadas. Este tipo de compromiso a largo plazo con un proyecto de software puede ser agotador, especialmente considerando la complejidad y la responsabilidad inherentes al mantenimiento de una biblioteca crítica.

• Falta de apoyo: Si bien XZ es un proyecto popular, está claro que Lasse Collin no ha recibido el nivel de apoyo que necesitaba para mantenerlo de manera sostenible. La falta de recursos y colaboradores podría haber contribuido a su sensación de agotamiento.

• Presión y responsabilidad: Ser el principal responsable de una biblioteca tan importante como XZ conlleva una gran presión y responsabilidad. Esta presión puede ser abrumadora y afectar negativamente el bienestar personal.

Tal vez, éste mensaje enviado por Lasse Collin, es una evidencia de la presión que estaba recibiendo por parte de Jigar Kumar, que lo llevaron a ceder el rol de mantenedor a Jia Tan. Dentro del mensaje se evidencia que para el, ser mantenedor del proyecto XZ es un hobby por el cual no recibe ningún tipo de retribución y que, al momento del ataque, tenía unos problemas de salud mental al largo plazo. (En la bibliografía están los mensajes de email más importantes de éste hilo).

Re: [xz-devel] XZ for Java

Lasse Collin Wed, 08 Jun 2022 03:28:08 -0700

On 2022-06-07 Jigar Kumar wrote:
> Progress will not happen until there is new maintainer. XZ for C has
> sparse commit log too. Dennis you are better off waiting until new
> maintainer happens or fork yourself. Submitting patches here has no
> purpose these days. The current maintainer lost interest or doesn't
> care to maintain anymore. It is sad to see for a repo like this.

I haven't lost interest but my ability to care has been fairly limited
mostly due to longterm mental health issues but also due to some other
things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and
perhaps he will have a bigger role in the future, we'll see.

It's also good to keep in mind that this is an unpaid hobby project.

Anyway, I assure you that I know far too well about the problem that
not much progress has been made. The thought of finding new maintainers
has existed for a long time too as the current situation is obviously
bad and sad for the project.

A new XZ Utils stable branch should get released this year withth
readed decoder etc. and a few alpha/beta releases before that.

Perhaps the moment after the 5.4.0 release would be a convenient moment
to make changes in the list of project maintainer(s).

Forks are obviously another possibility and I cannot control that. If
those happen, I hope that file format changes are done so that no
silly problems occur (like using the same ID for different things in
two projects). 7-Zip supports .xz and keeping its developer Igor Pavlovin
formed about format changes (including new filters) is important too.

--Lasse Collin

5 Un ataque sigiloso y audaz

La brecha en XZ no fue un ataque convencional. Se trató de una operación cuidadosamente planeada que se desarrolló durante varios años. Un hábil delincuente se infiltró en el equipo de desarrollo de la librería, ganando la confianza de sus miembros y eventualmente reemplazando al ingeniero principal, quien, cansado y con ganas de retirarse, estaba buscando un sucesor. Una vez en posición, el atacante incrustó un código malicioso en la librería, aprovechándose de su conocimiento del código y del proceso de desarrollo.

5.a Vector de ataque

Esta línea de tiempo revela un ataque de ingeniería social cuidadosamente orquestado durante muchos años y con mucha paciencia por parte del perpretador.

2021:

En 2021 un usuario que se hace llamar Jia Tan crea una cuenta en GitHub llamada JiaT75.

Sus primeros commits no los hace dirigidos hacia XZ pero son profundamente sospechosos en donde informaba de un error al desempaquetar archivos tar y proponía su solución. Una solución que involucró la introducción potencial de vulnerabilidades en el proyecto bdstar.

2022:

Jia Tan envía un parche por correo electrónico. Tras esto, surge una nueva persona, Jigar Kumar, que presiona al administrador del proyecto, Lasse Collin, para que fusione el parche y agregue otro administrador al proyecto XZ.

Dos cuentas aparentemente falsas, Jigar Kumar y Dennis Ens, participan en la presión a Lasse Collin para agregar al nuevo administrador.

JiaT75 comienza a contribuir regularmente al proyecto XZ, convirtiéndose finalmente en el segundo colaborador más activo. No está claro cuándo ganaron la plena confianza dentro de la comunidad.

2023:

JiaT75 gana la plena confianza al fusionar su primer compromiso en enero. Jia Tan reemplaza a Lasse Collin como contacto principal para el proyecto oss-fuzz de Google relacionado con XZ y se compromete la infraestructura para el exploit, con Jia Tan acreditado a pesar de haber sido escrito por Hans Jansen (otra cuenta aparentemente falsa).

Se realiza una solicitud de extracción en oss-fuzz para deshabilitar funcionalidades que podrían exponer los cambios maliciosos. Es decir, se introdujo código que permitiría, en el futuro, ocultar la introducción de cambios maliciosos. Además, JiaT75 plantea un problema aparentemente no relacionado que podría desviar la atención.

2024:

Una solicitud de extracción cambia la URL del proyecto en oss-fuzz de Google, lo que podría otorgarle a Jia más control.

Los pasos finales para el backdoor se implementan con mensajes de confirmación aparentemente inocuos ("Tests: Add a few test files").

Adicionalmente, las cuentas falsas comienzan a presionar a diferentes distribuciones para que incluyan la última versión de xz en las distribuciones Debian, Fedora, Ubuntu y otras.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

...This new version (5.6.1) fixes a valgrind bug with liblzma that outputs a false
warning that could affect existing testing frameworks for packages that
test with valgrind requiring a specific output. This release only fixes
bugs.Regards,
--Hans Jansen

5.b La vulnerabilidad y su impacto

La puerta trasera (backdoor) que se incrustó en el código de las versiones 5.6.0 y 5.6.1 permitía a un atacante ejecutar código arbitrario en cualquier sistema que utilizara la librería XZ. Como Linux, MacOS o sistemas que basaran su conectividad en OpenSSH como muchos proyectos de Google y de Oracle. Esto significa que el atacante podría haber tomado el control de servidores, redes y dispositivos en todo el mundo. El impacto potencial de la brecha era enorme, ya que XZ se utiliza en una amplia gama de sistemas, desde teléfonos inteligentes hasta supercomputadoras.

5.c La detección y la respuesta: Un esfuerzo comunitario

Afortunadamente, la brecha fue detectada a tiempo gracias a la atención de un usuario de OpenSSH: Andres Freund, quien al realizar un microbenckmark, notó un consumo inusual de CPU y una demora de 500 milisegundos en el proceso de conexión de la librería liblzma (parte de la librería XZ). Esta pequeña sospecha desencadenó una investigación que llevó a descubrir el código malicioso y la identidad del atacante. Esta investigación se evidencia en el mensaje de email https://www.openwall.com/lists/oss-security/2024/03/29/4:

Date: Fri, 29 Mar 2024 08:51:26 -0700
From: Andres Freund 
To: oss-security@...ts.openwall.com
Subject: backdoor in upstream xz/liblzma leading to ssh server compromise

5.d La respuesta rápida y eficaz de la comunidad del software libre

La comunidad del software libre reaccionó rápidamente a la brecha. A pesar de que la versión vulnerada de XZ alcanzó a estar en una PRE-RELEASE de Debian, nunca alcanzó a salir en una versión oficial. Se notificó a los usuarios que se habían actualizado a las versiones 5.6.0 y 5.6.1 que retornaran a la versión 5.4.0 o 5.2.5, que no habían sido vulneradas. Los desarrolladores de XZ trabajaron sin descanso para corregir la vulnerabilidad y publicar una nueva versión de la librería. Las distribuciones de Linux y otros proyectos de software actualizaron rápidamente sus sistemas para incluir la nueva versión. En cuestión de días, la amenaza se había mitigado.

5.e Lecciones aprendidas

• La brecha en XZ nos deja varias lecciones importantes. En primer lugar, demuestra que la seguridad del software libre no es un mito. La transparencia y la colaboración inherentes a este modelo permiten detectar y corregir vulnerabilidades de manera rápida y eficaz. En segundo lugar, destaca la importancia de la vigilancia y el monitoreo constantes. Un pequeño detalle, como una demora inusual en la transferencia de archivos, puede ser la señal de un problema grave. Por último, la brecha nos recuerda que la seguridad es un proceso continuo que requiere la participación de toda la comunidad.

• La brecha en XZ no fue un ataque a la seguridad del software libre, sino un ataque a la confianza. El atacante aprovechó la confianza de la comunidad para infiltrarse en el equipo de desarrollo y llevar a cabo su plan. Sin embargo, la respuesta rápida y eficaz de la comunidad demuestra que el software libre es un modelo robusto y seguro que cuenta con mecanismos para detectar y corregir vulnerabilidades. La brecha en XZ nos recuerda que la seguridad es una responsabilidad compartida y que todos debemos contribuir a mantener un ecosistema de software libre seguro y confiable.

6 Otros incidentes en software libre

La transparencia del código en el software libre, si bien presenta ventajas, también ha dado lugar a brechas de seguridad notables que han puesto en jaque a usuarios y organizaciones. Entre los ejemplos más conocidos se encuentran:

• Heartbleed: Esta vulnerabilidad, descubierta en 2014, afectó a la biblioteca OpenSSL utilizada en numerosos sitios web y servicios online. Permitía a los atacantes robar información sensible, como contraseñas y datos de tarjetas de crédito, de forma silenciosa. Sin embargo, a pesar de haber estado casi 2 años dentro del código fue detectada y corregida por un desarrollador antes de que alguien se aprovechara de la brecha. Ningún incidente de explotación de la vulnerabilidad fue reportado.
• Logjam: Esta falla, revelada en 2015, afectaba al protocolo TLS/SSL, utilizado para cifrar las comunicaciones en internet. Permitía a los atacantes interceptar y descifrar el tráfico con el mecanismo de Man In The Middle, poniendo en riesgo datos confidenciales cuando se utilizaban claves débiles Diffie-Hellman de 512 bits.
• KRACK: Esta brecha, descubierta en 2017, afectaba al protocolo WPA2, utilizado para asegurar las redes Wi-Fi. Permitía a los atacantes interceptar y descifrar el tráfico de datos, comprometiendo la privacidad y seguridad de las comunicaciones.
• GhostShell: Esta vulnerabilidad, revelada en 2019, afectaba a la biblioteca Ghost, utilizada para administrar y automatizar tareas en servidores Linux. Permitía a los atacantes ejecutar código arbitrario en los sistemas afectados, tomando control total de los mismos.

Es importante destacar que, a pesar de estas brechas de seguridad, el software libre sigue siendo una opción robusta y confiable para muchos usuarios y organizaciones. La transparencia del código, junto con el enfoque colaborativo de su desarrollo, permite una rápida detección y corrección de vulnerabilidades, lo que a su vez contribuye a mejorar continuamente la seguridad general del software.

7 Conclusiones

La brecha en XZ es un recordatorio de que la seguridad en el software libre no es una garantía, sino un proceso continuo que requiere la participación activa de toda la comunidad. Es fundamental que los desarrolladores de software libre mantengan un alto nivel de compromiso con la seguridad, pero también es crucial que los usuarios contribuyan reportando errores y vulnerabilidades potenciales.

Es importante que los usuarios que utilizan software libre sean conscientes de que no hay que matar a la gallina de los huevos de oro. El software libre les proporciona múltiples beneficios, como ahorro de costes, mayor libertad y acceso a un ecosistema de software innovador y en constante evolución. Es responsabilidad de los usuarios retribuir a la comunidad de software libre donando parte de las ganancias o el ahorro que les genera el uso de este software. Estas donaciones son esenciales para apoyar a los desarrolladores y mantener proyectos de software libre saludables y sostenibles.

Un equipo de desarrolladores comprometido y bien remunerado facilita los procesos orientados a garantizar la seguridad y la calidad del software libre. Cuando los desarrolladores cuentan con los recursos y el apoyo necesarios, pueden dedicar más tiempo y esfuerzo a la detección y corrección de vulnerabilidades, a la implementación de prácticas de seguridad sólidas y a la mejora general del software.

El hecho de que se haya detectado tan rápidamente la brecha con un detalle tan minúsculo como lo fueron 500 milisegundos de retraso en las comunicaciones que detectó y reportó un usuario demuestra el éxito del modelo del software libre en mantener seguros los sistemas cuando la comunidad es activa. La vigilancia constante y la colaboración entre desarrolladores y usuarios son pilares fundamentales para la seguridad del software libre.

La brecha en XZ también ha puesto de relieve la importancia de las comunidades de software libre fuertes y vibrantes. Una comunidad comprometida es más propensa a detectar y corregir vulnerabilidades de manera rápida y eficaz, y también es más probable que desarrolle prácticas de seguridad sólidas y fomente una cultura de seguridad dentro del proyecto.

En conclusión, la brecha en XZ no es una señal del fracaso del software libre, sino un recordatorio de que la seguridad es un desafío constante que requiere vigilancia y esfuerzo continuo. La transparencia y la colaboración inherentes al software libre, junto con la participación activa de la comunidad, la responsabilidad de los usuarios y la importancia de una comunidad activa, son herramientas poderosas para construir un ecosistema de software más seguro y confiable.

Bibliografía

• Sitio web oficial de XZ: https://en.wikipedia.org/wiki/XZ_Utils

• Documentación de XZ: https://www.sony-asia.com/electronics/support/mobile-phones-tablets-mobile-phones/xperia-xz/manuals

• Tutoriales de XZ: https://www.baeldung.com/linux/xz-compression

• https://boehs.org/node/everything-i-know-about-the-xz-backdoor

• Added error text to warning when untaring with bsdtar #1609 https://github.com/libarchive/libarchive/pull/1609/files

• https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html

• https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html

• https://www.mail-archive.com/xz-devel@tukaani.org/msg00568.html

• https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.html

• Anuncio de cambio de mantenedor y de sitio web: https://github.com/google/oss-fuzz/pull/11587

• Cuenta de Github de JiaT75: https://github.com/JiaT75

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

• https://mastodon.social/@AndresFreundTec/112180406142695845

• https://www.openwall.com/lists/oss-security/2024/03/29/4

• https://tukaani.org/xz-backdoor/

• Infografía: https://infosec.exchange/@fr0gger/112189232773640259

• Explicación técnica del funcionamiento del backdoor: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504

Licencia

Brecha en XZ: una demostración de la seguridad del software libre está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.