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)

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

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

Не распарсил

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень сомневаюсь что внутри гитхаба есть хоть какая-то часть стандартного гит-софта. Скорее всего у них своя реализация, изначально рассчитанная на очень много реп и большую нагрузку. Когда-то давно на старте, возможно, там и был обычный гит с обёрткой.

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

Ты можешь залить сам с чем-то дополнительным, но на вкладке release и tag всегда будут и автома ически сформированные архивы.

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

Если вы про страницу releases, то нет, туда надо заливать руками. Архив с сорцами в tar и zip подсасывается сам. А бинари извольте ручками.

PPP328 ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.