CVE-2024-3094: las versiones de xz utils que hay que quitar
Una cuenta de mantenedor publicó tarballs maliciosos de xz que podían alterar sshd en sistemas que enlazan a través de systemd. Las distribuciones estables casi no las habían sacado. Las que sí, tuvieron que bajar de versión el mismo día.
El 29 de marzo de 2024 Andres Freund escribió a oss-security sobre una puerta trasera en xz utils, asignada CVE-2024-3094. Las versiones afectadas son 5.6.0 y 5.6.1. La carga iba en el tarball de la release, no en el árbol de git que leería la mayoría de quienes revisan, y estaba cableada para interferir con sshd en distribuciones que notifican a systemd desde OpenSSH.
NVD la puntúa con 10,0. Freund la notó porque los inicios de sesión ssh iban lentos y usaban CPU de más en un Debian unstable. Por eso la campaña no se volvió en silencio el tráfico del año siguiente.
Qué llegó en el tarball
El proyecto tenía un mantenedor nuevo que, a lo largo de años, ganó la capacidad de cortar releases. Los tarballs 5.6.0 y 5.6.1 contenían archivos extra que el sistema de build recogía y que alteraban la biblioteca resultante. Las distribuciones que compilan OpenSSH con un parche para hablar con systemd podían terminar con un sshd que consultaba esa biblioteca.
Este artículo no describe el disparador ni la carga. El hecho operativo es el número de versión. Si el xz instalado es 5.6.0 o 5.6.1, reemplázalo. Si es una release 5.4, estás en la rama que no formó parte de esta puerta trasera.
Quién la distribuyó de verdad
Fedora Rawhide, Debian unstable y testing, y un puñado de imágenes rolling o de preview tenían las versiones malas a finales de marzo de 2024. Red Hat Enterprise Linux, Ubuntu LTS y Debian stable no habían promovido 5.6. Esa división es toda la diferencia entre un viernes malo y una reconstrucción de flota. También es por lo que 'usamos Linux' no es un inventario.
Los contenedores y las imágenes de integración fueron las copias silenciosas. Un Dockerfile que decía instalar xz contra una base rolling el 28 de marzo de 2024 pudo congelar la biblioteca mala en un artefacto que sobrevivió al rollback de la distro.
Baja de versión, y luego busca el artefacto
Instala el xz al que tu distribución volvió — 5.4.x en las ramas que publicaron un arreglo esa semana — y reinicia sshd para que el proceso no siga mapeado a la biblioteca vieja. Confirma la versión del paquete y el archivo en disco. CISA y las distros publicaron los hashes y los nombres de paquete; usa esos, no un espejo que no hayas comprobado.
Busca en imágenes y cachés 5.6.0 y 5.6.1. Reconstruye cualquier artefacto que las contuviera. Rotar las claves de anfitrión SSH es un extra razonable en una máquina que de verdad corrió el build malo y aceptó logins, porque no puedes ver qué hizo un sshd con puerta trasera. No sustituye quitar la biblioteca.
Qué conservar del incidente
Fija las imágenes base. Revisa quién puede publicar el tarball de una dependencia que corre en el espacio de direcciones de sshd. Un solo mantenedor con derecho de release y sin una segunda firma es la condición a la que esto tardó años en llegar.
El correo de Freund es la fuente primaria, y recuerda que la detección fue rendimiento, no una firma de escáner. Guarda telemetría suficiente de la latencia de login para que un sshd lento sea una página, no un encogimiento de hombros. El registro del CVE es el identificador del ticket de cambio.
El reporte de Andres Freund a oss-security el 29 de marzo de 2024, y la ficha de NVD de CVE-2024-3094.
https://nvd.nist.gov/vuln/detail/CVE-2024-3094
Preguntas frecuentes
¿Qué versiones de xz tienen la puerta trasera?
5.6.0 y 5.6.1. La línea 5.4 que usaban las distribuciones estables no formó parte de CVE-2024-3094. Baja de versión cualquier cosa que haya instalado el par 5.6, incluidas imágenes de contenedor construidas esa semana.
¿Cada servidor Linux necesitaba un parche de emergencia?
No. Las releases estables empresariales no habían publicado 5.6.0 ni 5.6.1. Las ramas rolling, testing y Rawhide sí. Comprueba la versión en vez de dar por hecho que el titular aplica a la flota.
¿Basta quitar el paquete?
Reemplaza el paquete y reinicia sshd para que la biblioteca vieja no siga mapeada. Reconstruye las imágenes que hornearon 5.6.0 o 5.6.1. Rota las claves de anfitrión si ese sshd de verdad corrió y aceptó conexiones.