ХабрПостыНовостиМегапосты?

CVE-2024-3094: бэкдор в популярной утилите XZ затрагивает множество популярных дистрибутивов Linux

Уязвимость CVE-2024-3094 в XZ Utils - популярной утилите сжатия формата XZ, включенной в большинство дистрибутивов Linux - может «позволить злоумышленнику нарушить аутентификацию sshd и получить удаленный несанкционированный доступ ко всей системе», предупреждает Red Hat.

CVE-2024-3094 и обход аутентификации OpenSSH

Причиной уязвимости на самом деле является вредоносный код, присутствующий в версиях 5.6.0 (выпущен в конце февраля) и 5.6.1 (выпущен 9 марта) библиотек xz, который был случайно обнаружен Андресом Фройндом, разработчиком и программистом PostgreSQL в Майкрософт.

«После наблюдения нескольких странных симптомов, связанных с liblzma (часть пакета xz) в установках Debian sid в течение последних недель (вход в систему с использованием ssh, отнимающий много ресурсов процессора, ошибки valgrind), я нашел ответ: upstream-репозиторий xz и xz-tarball содержали бэкдор»

— поделился он в списке рассылки oss-security.

О CVE-2024-3094

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

«В дистрибутиве Git отсутствует макрос M4, запускающий сборку вредоносного кода. Артефакты второго этапа присутствуют в репозитории Git для внедрения во время сборки на случай присутствия вредоносного макроса M4»

— добавили они.

Полученная вредоносная сборка мешает аутентификации в sshd через systemd

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

«Учитывая активность в течение нескольких недель, можно сделать вывод, что коммиттер либо непосредственно замешан в этом, либо имела место довольно серьезная компрометация их системы. К сожалению, последнее выглядит менее вероятным объяснением, учитывая, что они сообщали в различных списках об «исправлениях» [ошибок, вызванных внедренным кодом в версии 5.6.0]»

— прокомментировал Фройнд.

«К счастью, xz 5.6.0 и 5.6.1 еще не широко интегрированы в дистрибутивы Linux, а где и были, в основном в предварительных версиях».

Какие дистрибутивы затронуты?

Red Hat сообщает, что уязвимые пакеты присутствуют в Fedora 41 и Fedora Rawhide, и призывает пользователей этих дистрибутивов немедленно прекратить их использование.

«Если вы используете уязвимый дистрибутив в бизнес-среде, мы рекомендуем вам связаться с вашей командой по информационной безопасности для дальнейших действий»

— сказали они и добавили, что ни одна версия Red Hat Enterprise Linux (RHEL) не затронута.

SUSE выпустила исправление для пользователей openSUSE.

Debian утверждает, что никакие стабильные версии дистрибутива не затронуты, но что скомпрометированные пакеты были частью тестовых, нестабильных и экспериментальных дистрибутивов Debian, и пользователи этих дистрибутивов должны обновить пакеты xz-utils.

«Вредоносный код, обнаруженный в последних версиях библиотек xz, показывает, насколько важно иметь бдительную и опытную команду безопасности Linux, контролирующую каналы цепочки поставок программного обеспечения»

— рассказал Help Net Security Винсент Данен, вице-президент по безопасности продуктов в Red Hat.

«Red Hat вместе с CISA и другими дистрибутивами Linux смогли идентифицировать, оценить и помочь устранить эту потенциальную угрозу, прежде чем она стала представлять значительный риск для более широкого сообщества Linux»

CISA посоветовала разработчикам и пользователям понизить версию XZ Utils до нескомпрометированной версии (например, XZ Utils 5.4.6 Stable), а также отслеживать любые вредоносные действия и сообщать агентству о любых положительных результатах.

Kali Linux объявила, что влияние этой уязвимости затронуло Kali в период с 26 по 29 марта. Если вы обновили установку Kali 26 марта или позже, применение последних обновлений сегодня имеет решающее значение для решения этой проблемы. Однако, если вы не обновили установку Kali до 26-го числа, эта бэкдор-уязвимость не затрагивает вас.

UPD

@pentestit-team
30.03.2024 09:30 UTC
Первоисточник

Комментарии

@mpa4b
30.03.2024 06:23 UTC
+15

Лучшая иллюстрация того, что оголтелая интеграция всего со всем до добра не доводит. liblzma в sshd появилась из-за того, что мейнтейнеры редхатов и дебианов нарукосуйничали зависимость от libsystemd, запатчив сорцы openssh. В дистрибах без системгэ sshd не связывается с liblzma.

Сама атака явно не один год готовилась, выбирался компонент с 'vulnerable' мейнтейнером и т.д.

30.03.2024 09:14 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
30.03.2024 15:12 UTC
0

Генту с тильдой не пострадала, хотя и liblzma там 5.6.х была (уже откатили). По крайней мере у меня. Без systemгэ (OpenRC).

30.03.2024 19:38 UTC
+19

30.03.2024 20:25 UTC
0

Да, это почти про меня (привычка пользоваться дебианом oldstable, иногда oldoldstable).

31.03.2024 17:03 UTC
0

Для каких целей, интересно? Если dns какой-то держать или роутер домашний или офисный с фаерволом, то это понятно, но разве не нужен вам современный софт.

01.04.2024 10:13 UTC
+1

Обычные UNIX (ладно-ладно, Linux — хотя и OpenBSD немножко есть) сервера: SSH, VPN, rsync, GPG, Apache, Nginx, Exim / postfix, mySQL, SVN, KVM/qemu, Munin / Zabbix etc. Всё достаточно устоявшееся, чтобы не гнаться за самым свежим.

30.03.2024 20:45 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
@emoxam
30.03.2024 07:38 UTC
+2

Это как-то связано с компрессией трафика ssh? Или откуда xz в ssh?

30.03.2024 08:36 UTC
+19

Нет. Это из-за ленивой реализации 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.

30.03.2024 17:39 UTC
+7

В догонку ко мнениям ыкспертов с 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.

01.04.2024 05:50 UTC
0

Спасибо, отличный пример того, что не стоит ради одной функции подключать целую стороннюю библиотеку.

А иногда фича превращается в баг: (к сожалению не могу вспомнить где) некие гении реализовали интерпретацию входящих аргументов (точнее, парсинг параметров запроса). С одной стороны удобно и круто, но быстро нарисовалась и другая сторона: уязвимость выполнения исполняемого кода с любыми некрасивыми целями.

Т.е. не всегда больше - значит лучше.

@Jipok
30.03.2024 08:32 UTC
+5

На опеннете больше подробностей

https://www.opennet.ru/60877

@Jipok
30.03.2024 08:38 UTC
+6

Скрипт от Патрика который определяет есть ли у вас в системе бекдор

if hexdump -ve '1/1 "%.2x"' /lib*/liblzma.so.5 | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 ; then
  echo probably vulnerable
else
  echo probably not vulnerable
fi 

30.03.2024 11:45 UTC
+1

этот скрипт не работает если либа в /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 этого кода нет

30.03.2024 12:36 UTC
0

open suse после обновления упала до 5.4.6

@0xC0CAC01A
30.03.2024 20:32 UTC
+7

Интересно, а сколько таких бэкдоров в опенсорсе ещё не обнаружено?

Ну и было бы интересно прочитать про расследование, кто и как такой бэкдор организовал.

31.03.2024 12:08 UTC
0

сделали

31.03.2024 19:50 UTC
+6

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