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)

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

Если язык не будет позволять создавать цикл, раскрывать по тупому переменные внутри строк, то не сможешь. Сборочная система не должна быть языком программирования.

Это если что от авторов CMake, профессионалов своего дела, обычный программист напишет хуже.

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

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

Чойта не должна.

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

Если язык не будет позволять создавать цикл, раскрывать по тупому переменные внутри строк, то не сможешь. Сборочная система не должна быть языком программирования.

Смогу. Если ты посмотришь на стандартный сценарий meson, он выглядит вот так: https://github.com/swaywm/sway/blob/master/meson.build

Там все понятно и нет страшной магии.

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

Если язык не будет позволять создавать цикл, раскрывать по тупому переменные внутри строк, то не сможешь. Сборочная система не должна быть языком программирования.

Это если что от авторов CMake, профессионалов своего дела, обычный программист напишет хуже.

А я поддержку этого оратора, хоть он и морковка. Язычок сборочной системы не должен быть Тьюринг-полным. Никогда.

Cmake впрочем сосёт, но по другим причинам. Но даже в таком виде он на порядок лучше автолулзов.

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

Язычок сборочной системы не должен быть Тьюринг-полным. Никогда.

Не должен – не пользуйся. Другим это удобно. Твои личные проблемы по барабану.

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

Другим это удобно

Поэтому автолулзы выкидывают все кто может, да?

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

Не должен – не пользуйся. Другим это удобно.

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

DSL должен быть расширяемым, например, модулями, которые уже можно на любом языке писать. Но

  1. сам DSL всё ещё не должен быть Тьюринг-полным
  2. их использование должно быть сведено к минимуму

Как отличный пример, есть Cabal в хачкелле. Язычок абсолютно топорен и просто позволяет описывать цели со стандартными свойствами. В 98% проектов абсолютно хватает стандартных средств. Для оставшихся можно немного расширений на том же хацкелле написать, чтобы сделать сборку интереснее.

Ну или Rust + Cargo с опциональным build.rs туда же.

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

Погоди, а Nix?

Nix – не сборочная система для софта.

Он turing complete?

Не совсем. Там нет циклов и бесконечной рекурсии. Хотя всегда можно дёрнуть внешний скрипт, который будет висеть вечно.

Какое двуличие, Карл?

Ну и nix сосёт довольно сильно, да. Я с этим даже спорить не буду.

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