Compromiso de servidores SSH por una puerta trasera presente en el flujo ascendente de xz/liblzma

• En instalaciones de Debian sid se observaron algunos síntomas extraños relacionados con liblzma (parte del paquete xz), como mayor uso de CPU al iniciar sesión por SSH y errores de valgrind
• Se descubrió que la causa del problema era que el repositorio upstream y los tarballs de xz estaban infectados con una puerta trasera. Parte de la puerta trasera solo existe en los tarballs distribuidos
• El script incluido en el tarball se ejecuta al final de configure y, si se cumplen ciertas condiciones, modifica $builddir/src/liblzma/Makefile para insertar código malicioso

Puerta trasera en el repositorio

• La parte principal de la puerta trasera existe en forma cifrada dentro del directorio tests/files del repositorio
• Estos archivos no se usaron en las pruebas de la versión 5.6.0, y en la versión 5.6.1 hubo intentos de corregir errores de valgrind y fallas provocadas por la puerta trasera

Sistemas afectados

• El script de la puerta trasera se invoca por primera vez después de configure y solo modifica el proceso de compilación bajo ciertas condiciones específicas (por ejemplo, sistemas Linux x86-64, uso de gcc y del enlazador GNU, y compilación de paquetes Debian o RPM)

Impacto en el servidor openssh

• Cuando se usa liblzma instalado con la puerta trasera, el inicio de sesión por SSH se vuelve más lento
• openssh no usa liblzma directamente, pero algunas distribuciones, incluido Debian, aplican parches a openssh para admitir notificaciones de systemd, y libsystemd depende de lzma

Análisis del código inyectado

• El análisis se realiza desde la perspectiva de un observador que no es investigador de seguridad ni experto en ingeniería inversa
• La puerta trasera intercepta la ejecución mediante un ifunc resolver y, durante la inicialización de sshd, resuelve símbolos para reemplazar el símbolo RSA_public_decrypt con su propio código

Impacto en sshd

• Se modifica RSA_public_decrypt@....plt para que apunte al código de la puerta trasera, de modo que dicho código se invoque durante el inicio de sesión con clave pública
• Se presume que esto permite omitir la autenticación o posibilitar la ejecución remota de código

Reporte del bug

• No se reportó como bug porque se sospechaba la participación del repositorio upstream
• Red Hat asignó a este problema el CVE-2024-3094

Detección de instalaciones vulnerables

• Se proporciona un script para detectar si el binario ssh del sistema es vulnerable

[depth221]

Todo lo que sé sobre la puerta trasera de xz
Este es un texto escrito por Andres Freund, quien descubrió esa puerta trasera.

[edunga1]

Es sorprendente lo meticulosamente que se movieron;; el proceso parece de película.

[carnoxen]

Aunque lo descuarticen, se lo merece.

[roxie]

¿Por qué?

[keepworking]

Como fue un acto de insertar intencionalmente una puerta trasera en el código abierto... en el proceso también hicieron cosas como manipular discretamente la opinión pública.
Antes también hubo casos de insertar vulnerabilidades de forma maliciosa en el kernel de Linux, así que es bastante amargo.

[roxie]

Ah, creo que ahora ya entendí el matiz. Gracias.

[GN⁺]

Opiniones de Hacker News

• Enlaces relacionados:

  • Xz: Disable ifunc to fix Issue 60259
  • FAQ sobre la puerta trasera en xz-utils
  • Todo lo que sé sobre la puerta trasera de XZ

• Resumen:

  • El autor de la puerta trasera estuvo comunicándose durante varias semanas para intentar añadir xz 5.6.x a Fedora 40 y 41. Colaboró para resolver los problemas de valgrind causados por esta puerta trasera, pero al final se descubrió que la propia puerta trasera era la causa del problema. Después de que por error se rompiera el período de embargo, hubo que resolver el problema con urgencia.
  • Uno de los autores de la puerta trasera desactivó directamente en oss-fuzz una función que dependía de la puerta trasera para evitar que se descubriera accidentalmente.
  • El autor de la puerta trasera añadió un archivo SECURITY.md al proyecto xz-java. Este incluye instrucciones para que, si se encuentra una vulnerabilidad de seguridad, no se haga pública y se reporte de forma privada. Visto desde otra perspectiva, puede interpretarse como un intento de ganar tiempo para ajustar su exploit y aprovechar los objetivos.
  • openssh no usa liblzma directamente, pero Debian y varias distribuciones aplican parches a openssh para dar soporte a notificaciones de systemd. Esto hace que libsystemd dependa de liblzma, añadiendo dependencias extra a demonios críticos para la seguridad como openssh y aumentando el riesgo de ataques a la cadena de suministro.
  • Puntos clave para quienes están en pánico:
    • Si usas una versión reciente de liblzma5 (5.6.0 o 5.6.1). Esto se añadió aproximadamente durante el último mes.
    • Si usas una distribución de Linux basada en Debian o RPM. Parece haber sido un intento de dificultar la ingeniería inversa.
    • Si ejecutas OpenSSH sshd desde systemd. El OpenSSH parcheado en algunas distribuciones usa libsystemd para funciones de registro, y eso arrastra la versión vulnerable de liblzma5.
    • Debian testing ya tiene una versión llamada 5.6.1+really5.4.5-1, que en realidad es la versión anterior 5.4 reempaquetada como si fuera una nueva versión.
  • Si quisieras esconder algo sospechoso en GNU autoconf, lo esconderías ahí y no en un script curl | sh. La persona que distribuyó esto ya se había encargado de distribuciones antes y empezó a hacer commits desde 2022. Hay commits con muchos cambios reales, y también commits en proyectos relacionados como libarchive. Hizo falta mucho esfuerzo para insertar la puerta trasera.
  • Hace algunos años alguien escribió una librería de Go que envuelve el código C de xz para permitir compresión xz desde Go. Hace alrededor de una semana recibió el primer PR en ese repositorio para actualizar a 5.6.1. Era de una cuenta de GitHub distinta a la del upstream.
  • A un colaborador que no es investigador de seguridad ni ingeniero de reversa le gusta escribir textos técnicos. Su informe, que resume sus hallazgos, se considera una gran plantilla para colaboradores fuera del mundo principal del debugging que suelen mostrarse reacios a compartir.
  • Si imaginamos un intento de puerta trasera más sofisticado contra xz(1), probablemente no se habría descubierto tan rápido. xz se usa prácticamente en todas partes. Podría crearse una versión de xz que modifique selectivamente solo pequeñas partes de archivos como tarballs de software .tar.xz, usados como base de ciertos procesos de compilación. El objetivo no serían tarballs con código fuente, sino tarballs que distribuyen binarios precompilados.