Комментарии 19
Лучшая иллюстрация того, что оголтелая интеграция всего со всем до добра не доводит. liblzma в sshd появилась из-за того, что мейнтейнеры редхатов и дебианов нарукосуйничали зависимость от libsystemd, запатчив сорцы openssh. В дистрибах без системгэ sshd не связывается с liblzma.
Сама атака явно не один год готовилась, выбирался компонент с 'vulnerable' мейнтейнером и т.д.
>В дистрибах без системгэ sshd не связывается с liblzma
И что, void (успевший обновиться до 5.6) типа не пострадал?
В целом, реакция на событие излишне нервная, ибо нормальные серверные дистрибы не пострадали.
Генту с тильдой не пострадала, хотя и liblzma там 5.6.х была (уже откатили). По крайней мере у меня. Без systemгэ (OpenRC).
даже если есть systemd, но не стали патчить openssh, проблемы нет, ну во всяком случае для openssh-сервера.
Например для генту:
In Gentoo, we don't patch net-misc/openssh with systemd-notify support which means liblzma, at least in the normal case, doesn't get loaded into the sshd process
Это как-то связано с компрессией трафика ssh? Или откуда xz в ssh?
Нет. Это из-за ленивой реализации systemd notifications.
Умники-разумники из популярных дистро вместо того, чтобы самим реализовать достаточную часть протокола — вызвать getenv("NOTIFY_SOCKET"), открыть указанный там сокет, написать туда в нужный момент 8 байт ("READY=1\n"), закрыть сокет и вызвать unsetenv() — решили слинковаться с libsystemd ради одной функции, совершающей вышеперечисленные шаги, и притащили в адресное пространство вагон зависимостей этой libsystemd вроде libcurl, liblzma, libmount и ещё десятка чего-то там. Этим бекдор и пользуется, вмешиваясь в работу dynamic linker, о чём довольно подробно написано в рассылке oss-security.
Умник №1: https://salsa.debian.org/ssh-team/openssh/-/commit/59d17e908...
Умник №2: https://src.fedoraproject.org/rpms/openssh/blob/176421c4e42b...Функция sd_notify() не дёргает liblzma, для бекдора этого не надо. Т. н. "systemd notifications" можно реализовать без libsystemd, и этот протокол применяется не только в systemd (ещё в QEMU).
Извращение добавили те дистро, что впатчили сборку с libsystemd.
В догонку ко мнениям ыкспертов с opennet'а комментарий самого Поттеринга (автора systemd):
Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. In particular non-C environments really should do their own native impl and not botjer wrapping libsystemd just for this.
But let me stress two other things:
Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.
Спасибо, отличный пример того, что не стоит ради одной функции подключать целую стороннюю библиотеку.
А иногда фича превращается в баг: (к сожалению не могу вспомнить где) некие гении реализовали интерпретацию входящих аргументов (точнее, парсинг параметров запроса). С одной стороны удобно и круто, но быстро нарисовалась и другая сторона: уязвимость выполнения исполняемого кода с любыми некрасивыми целями.
Т.е. не всегда больше - значит лучше.
На опеннете больше подробностей
Скрипт от Патрика который определяет есть ли у вас в системе бекдор
if hexdump -ve '1/1 "%.2x"' /lib*/liblzma.so.5 | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 ; then
echo probably vulnerable
else
echo probably not vulnerable
fi 
этот скрипт не работает если либа в /usr/lib/x86_64-linux-gnu
нужен какой то locate или тупо указать этот путь в командной строке
hexdump -ve '1/1 "%.2x"' /usr/lib/x86_64-linux-gnu/liblzma.so.5 | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
но как по мне проще набрать xz --version
я нашел этот код только в rolling версии opensuse и то там 5.6.0
в ARCH с 5.6.1 этого кода нет
Интересно, а сколько таких бэкдоров в опенсорсе ещё не обнаружено?
Ну и было бы интересно прочитать про расследование, кто и как такой бэкдор организовал.
сделали
Полагаю, что в закрытом софте, распространяемом исключительно в бинарном виде, их всегда было и будет больше, чем в опенсорсе. В закрытом их сложнее обнаруживать, но скандалов-интриг-расследований на эту тему тоже хватает (чаще всего в последние годы что-то находят в прошивках всяких роутеров и андроид-телефонов).
CVE-2024-3094: бэкдор в популярной утилите XZ затрагивает множество популярных дистрибутивов Linux