LINUX.ORG.RU

В коде xz версий 5.6.0 и 5.6.1 обнаружен бэкдор

 ,


4

9

Разработчик Debian и исследователь в сфере информационной безопасности Andres Freund сообщает об обнаружении вероятного бэкдора в исходном коде xz версий 5.6.0 и 5.6.1.

Бэкдор представляет собой строчку в одном из m4-скриптов, которая дописывает обфусцированный код в конец скрипта configure. Этот код затем модифицирует один из сгенерированных Makefile проекта, что в конечном итоге приводит к попаданию вредоносной нагрузки (замаскированной под тестовый архив bad-3-corrupt_lzma2.xz) непосредственно в исполняемый файл библиотеки liblzma.

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

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

По ссылке исследователь отмечает, что в конечном итоге целью бэкдора, по-видимому, является инъекция кода в процесс sshd и подмена кода проверки RSA-ключей, и приводит несколько способов косвенно проверить, исполняется ли вредоносный код на вашей системе в данный момент.

Рекомендации по безопасности были выпущены проектами Arch Linux, Debian, Red Hat и openSUSE.

Разработчики Arch Linux отдельно отмечают, что хотя заражённые версии xz и попали в репозитории дистрибутива, дистрибутив остаётся в относительной «безопасности», т. к. sshd в Arch не линкуется с liblzma.


Проект openSUSE отмечает, что ввиду запутанности кода бэкдора и предполагаемого механизма его эксплуатации сложно установить «сработал» ли он хотя бы раз на данной машине, и рекомендует полную переустановку ОС с ротацией всех релевантных ключей на всех машинах, на которых хотя бы раз оказывались заражённые версии xz.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: ilinsky (всего исправлений: 2)

Ожидаемо — хорошую вещь XZ бы не назвали.

Smacker ★★★★★
()

Особенность инцидента состоит в том, что вредоносный код содержится только в распространяемых tar-архивах с исходным кодом и не присутствует в git-репозитории проекта.

Сообщается, что человек, от чьего имени вредоносный код был добавлен в репозиторий проекта

Не распарсил

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Бинарник, замаскированный под архив, в репозитории, а «триггер» — только в релизных тарболлах. По крайней мере я так понял анонс.

Прошу прощения за неточность формулировок, торопился.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

MrClon ★★★★★
()
Ответ на: комментарий от MrClon

Это указывает на то что либо процесс формирования релизных тарболов похачили, либо кто-то причастный к этому процессу в деле

Ровно об этом и написано в тексте новости.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от MrClon

Подробнее, courtesy of LWN:

The exploit is in two parts. Two «test files» which contain the payload; and a modified m4 script (m4/build-to-host.m4) which initiates the process of loading the payload. The test files were added first and are part of git. They don’t do anything on their own. The m4 modification was only made in the github tarball, somewhat later, and it’s not checked into git. (It was a surprise to me that github release tarballs aren’t just tarred up copies of the git checkout.)

Having said all that, I wouldn’t rely on any version of xz which «Jia Tan» (a pseudonym, I assume) has touched, and unfortunately he’s been contributing to xz and been an upstream committer for 2+ years.

(ref: https://lwn.net/Articles/967205/)

intelfx ★★★★★
() автор топика

даже в моей бубунте 5.2, а дебиан это вообще не про свежесть версий

bernd ★★★★★
()
Ответ на: комментарий от MrClon

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

PPP328 ★★★★★
()
Ответ на: комментарий от hateyoufeel

лол решето!!

"– У нас в системе безопасности дыра!

– У нас что-то есть в системе безопасности?"

luke ★★★★★
()

Дверь мне запили запакуй!

perl5_guy ★★★★★
()
Ответ на: комментарий от PPP328

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

Вообще нет, чаще всего архивы там делаются гитом автоматически. Если качаешь https://github.com/lol/project/archive/<коммит, тег или ветка>.tar.gz, то это будет именно код из git. У xz какого-то хрена архивы формировались скриптом то ли в CI, то ли вообще руками.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

У этого механизма есть минус: они в автоматически генерируемые архивы не кладут сабмодули, а стоило бы. :)

a1ba ★★
()

That line is not in the upstream source of build-to-host, nor is build-to-host used by xz in git. However, it is present in the tarballs released upstream, except for the «source code» links, which I think github generates directly from the repository contents

Как такое вообще могло случиться? Эти архивы же пакуются автоматом, из кода, который там в git. Уж не диверсия ли это со стороны M$?

CrX ★★★★★
()
Ответ на: комментарий от a1ba

У этого механизма есть минус: они в автоматически генерируемые архивы не кладут сабмодули, а стоило бы. :)

Сабмодули в гите – это сплошной позор. В том числе и из-за этого.

hateyoufeel ★★★★★
()
Ответ на: комментарий от CrX

Нет, это релизные тарболлы которые собирает для вас мейнтейнер. Причём с выполненным autoreconf, который генерирует configure скрипт. Это не единственный такой проект у которого релизный тарболл отличается того, что внутри git репозитория.

Впрочем, никто не запрещает вручную забирать с тега и вызывать autoreconf самостоятельно. Я надеюсь, что мейнтейнеры дистрибутивов так и будут впредь делать. В Arch Linux, например, уже есть соответствующее изменение в PKGBUILD.

a1ba ★★
()
Последнее исправление: a1ba (всего исправлений: 1)

конечном итоге целью бэкдора, по-видимому, является инъекция кода в процесс sshd и подмена кода проверки RSA-ключей

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

dimgel ★★★★★
()
Ответ на: комментарий от CrX

That line isnotin the upstream source of build-to-host, nor is build-to-host used by xz in git. However, it is present in the tarballs released upstream, except for the «source code» links, which I think github generates directly from the repository contents

Как такое вообще могло случиться? Эти архивы же пакуются автоматом, из кода, который там в git. Уж не диверсия ли это со стороны M$?

Нет, там какой-то китаец два года коммитил в xz. В том числе и вот это.

Так что всем в идеале стоит откатиться на версию до появления этого китайца – 5.3.3.

hateyoufeel ★★★★★
()

я так понимаю бекдор только запускается при билде? В самом xz бэкдора нету?

mrdeath ★★★★★
()

Чувак говорит, что нашел бэкдор из-за тормозов ssh. Столько времени потратили на обфускацию и внедрение, а потом так тупо спалиться.

voltmod ★★★
()

Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:

ldd «$(command -v sshd)»

Охохо, эхехе, ихихи.

У нас в раче как обычно всё через жопу, даже бекдор нормально не работает.

// Арчевод

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

У нас в раче как обычно всё через жопу, даже бекдор нормально не работает.

Народ! Как пропатчить бэкдор под FreeBSD?!

dimgel ★★★★★
()
Ответ на: комментарий от intelfx

Звучит как проблема шитхаба, а не сабмодулей, не?

Не уверен. Там скорее всего тупо git archive под капотом дёргается.

hateyoufeel ★★★★★
()
Ответ на: комментарий от dimgel

sshd не зависит непосредственно от liblzma. А, вот, systemd - да. И благодаря нему и осуществляется атака.

gag ★★★★★
()
Ответ на: комментарий от gag

А, вот, systemd - да

В таком случае – как хорошо, что у меня artix без systemd. :)

dimgel ★★★★★
()

m4-скриптов

ААААААААААААА! Оно живое!!!!!

Как я счастлив, что забыл, как конфигурировать sendmail...

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)

Это какой-то… …позор. А самое печальное, что у меня этот пакет успел обновиться недавно до проблемной версии на одной из личных тачек. Придётся теперь ОС переустанавливать, так как я параноик, лучше перебдеть, чем недобдеть и т.п.

lucentcode ★★★★★
()
Ответ на: комментарий от hateyoufeel

Нет, там какой-то китаец два года коммитил в xz. В том числе и вот это.

И не только кто-то под тем аккаунтом, который может переводиться как Джон Смит или типа того, а и ещё под другим, который, к тому же, протолкнул «улучшенную» версию побыстрее в Дебиан, а то слишком много людей всполошилось из-за ругающегося valgrind (я это тоже заметил, ещё удивился, как это в lzma проглядели). Но, как оказалось, было уже поздно, так как кто-то заинтересовался этим вопросом вплотную.

А вот проверку fuzz’ером удалось отключить заблаговременно: https://github.com/google/oss-fuzz/pull/10667 (07.07.2023).

gag ★★★★★
()
Ответ на: комментарий от undef

К сожалению, оно и в тестинг успело попасть, и вот уже 3 недели как:

[2024-03-05] xz-utils 5.6.0-0.2 MIGRATED to testing (Debian testing watch)

gag ★★★★★
()
Ответ на: комментарий от Shadow

ААААААААААААА! Оно живое!!!!!

Там внутри обычная дидово-какерская Shell/Bash-дрисня которая замаскировала бэкдор: Бэкдор в xz/liblzma (комментарий)

Основная проблема именно в ней, во всём этом нагромождении какерских костыльков UNIX-like мирка: m4, shell/bash, make, sed, awk и пр.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Думаю, это всё из-за GNU башизмов. С ash или zsh не прокатило бы!

Shadow ★★★★★
()
Ответ на: комментарий от EXL

Основная проблема именно в ней, во всём этом нагромождении какерских костыльков UNIX-like мирка: m4, shell/bash, make, sed, awk и пр.

Причём это ещё и ~17 лет назад, когда я впервые познакомился с лялепсом, это казалось устаревшей ерундой.

mono ★★★★★
()

Ядерный звиздец. Как хорошо, что я не обновляюсь.

Vilicus
()
Ответ на: комментарий от SL_RU

В апстриме арча пофикшено

А вот и не пофикшено, так как фиксить было нечего. Результат дизассемблирования «пофикшенной» библиотеки на 100% совпадает с «непофикшенным». А все потому, что бекдор активируется только при сборке RPM или DEB (проверка переменных окружения и существования файла debian/rules).

AEP ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.