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)

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

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

Да всё там просто с языком. Харош придуриваться, от современного разраба нужно знать всё подряд, начиная от SQL, и заканчивая умением править конфиги, оформленные в наркоманском стиле YAML. А тут видите ли m4 проблемой стал.

Проблема в раздутом API самих автотулзов, помноженном на то, что в итоге это всё превращается в код на sh.

Можно было на том же m4 сделать всё намного удобнее для человека.

А старьё из проекта можно было давно выпилить.

Но внутри это типичный «хакирский софт», состоящий их кучи частных случаев без архитектуры. Всё в стиле того самого GNU из 90-х.

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

А тут видите ли m4 проблемой стал.

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

Но внутри это типичный «хакирский софт», состоящий их кучи частных случаев без архитектуры. Всё в стиле того самого GNU из 90-х.

Ну да, всё так.

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

Ну ты попробуй написать и отладить пару макросов на m4 под автолулзы.

Писал.

wandrien ★★
()
Ответ на: комментарий от cvs-255

Можно было давно всем взять и договориться использовать для управления конфигурацией сборки какую-нибудь несложную тулзу со вшитым lua.

Тем более, их таких аж несколько штук проектов есть.

Но когда у нас в индустрии вообще работало «всем взять и разумно договориться»? Никогда.

В итоге имеем наркоманский autotools, наркоманский cmake и еще meson на питоне.

Выбор питона для разработки такой тулзы это просто топ, 12 жирносов из 10 возможных.

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

Я не предлагаю всем договориться использовать тулзу X. Я предлагаю договориться НЕ использовать автошит

cvs-255 ★★★★★
()
Ответ на: комментарий от wandrien

Если не требуются специфичные Meson модули, то этим вполне можно пользоваться.

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

Намного быстрее. Даже 3D рендер через трассировку лучей на нём сделали для прикола: https://github.com/annacrombie/meson-raytracer.

Стоит отметить что скрипт сборки Mesin исполняется только в процессе конфигурирования, за собственно процесс сборки отвечает Ninja.

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

Конкретно Muon использует не Ninja, а Samurai, я его где-то год назад тестировал на своём проекте, в моём случае он отрабатывал медленнее чем Ninja.

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

Можно пользоваться чем больше нравиться: и Ninja, и Samurai. Samurai скорее для минимизации зависимостей.

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

Намного быстрее. Даже 3D рендер через трассировку лучей на нём сделали для прикола: https://github.com/annacrombie/meson-raytracer.

Почти в 84 раза быстрее. Молодцы.

Стоит отметить что скрипт сборки Mesin исполняется только в процессе конфигурирования,

Ну да. То же верно и для autotools, и для cmake.

question4 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.