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)

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

Ты проигнорировал всё и ничего не ответил. Давай я тебе вопрос задам: почему cmake написан на сишке, а не на самом себе?

Сука, в квотезы.

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

Нет. На meson ты можешь писать понятные вещи,

Я тебе о том, что код внедрения зловреда был обфусцирован, а писать обфусцированный код можно на любом ЯП, будь там хоть Питон, хоть C#.

на m4 это невозможно в принципе, там все будет лапша.

Да?

AC_DEFUN([SDE_WITH], [
    AC_ARG_WITH([$1],
        [AS_HELP_STRING(
            [--with-$1],
            [$2]
        )],
        [with_$1=$withval],
        [with_$1=auto]
    )

    AC_MSG_CHECKING([--with-$1])
    AC_MSG_RESULT([$with_$1])

    have_$1=no
    AS_IF([test "x$with_$1" != xno], [
        $3
    ])

    AS_IF([test "x$with_$1" = "xyes" -a "x$have_$1" != "xyes"], [
        AC_MSG_ERROR([$1 requested but not found])
    ])
])

лапша

Так про любой незнакомый ЯП можно сказать «лапша».

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

Ооо, это мое любимое:

    AS_IF([test "x$with_$1" = "xyes" -a "x$have_$1" != "xyes"], [
        AC_MSG_ERROR([$1 requested but not found])
    ])

Ты понимаешь что поставив тут " не в том месте можно получить shell execution, да?

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

чтобы прочитать мог язык/иде, а далее дать тебе ассист, чтобы ты не «читал глазами» тысячи строк.

Мечта говнокодеров о чудо-IDE, которая позволит «не читать код».

Ржу.

Вот потом таким бэкдоры во все места и засовывают со свистом.

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

Я тебе о том, что код внедрения зловреда был обфусцирован, а писать обфусцированный код можно на любом ЯП, будь там хоть Питон, хоть C#.

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

P.S. Но вообще это все мертвому припарки, потому что дыра была спрятана в релизном тарболе в который обычно никто не смотрит.

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

Это всё, что можешь ответить? Ну вот, достойно. А зачем пытался что-то рассказывать, если всё равно слился?

Сливайся хотя бы не так позорно, попытайся ответить.

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

Это всё, что можешь ответить? Ну вот, достойно. А зачем пытался что-то рассказывать, если всё равно слился?

Прости, но после тейка «почему бы не написать cmake на cmake» я не знаю что можно добавить. Ну, наверное то, что язык для описания сборочной системы немножко не такой выразительный, как язык программирования общего назначения?

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

Ты понимаешь что поставив тут " не в том месте можно получить shell execution, да?

А поставив звёздочку не в том месте, можно получить Segmentation Fault. Ты меня программными ошибками решил напугать или что?

получить shell execution

Получить shell execution на билд-машине, которая и так исполняет любой код? Охереть страшная у тебя модель угроз.

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

Получить shell execution на билд-машине, которая и так исполняет любой код? Охереть страшная у тебя модель угроз.

Ну как бы это и произошло. Читающий ожидал что проходит тест, а этот тест патчил только что скомпилированный бинарник.

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

Получить shell execution на билд-машине, которая и так исполняет любой код? Охереть страшная у тебя модель угроз.

Так в сабжевом посте ровно так говнокод в си и присунули :)

Пара кавычек не в том месте, из тестового бинарика выкалупывается ништячок, суётся куда надо и… PROFIT!

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

При этом даже простых карт с поддержкой 2D-ускорения (не 3D!) хватало уже

Ну как бы так же можно сказать, что 486+VGA хватало для игры дум, а теперь вот киберпанк тормозит.

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

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

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

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

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

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

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

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

Ну как бы это и произошло.

Нет, произошло не это. Билд-машина запускает произвольный исполняемый файл, который делает произвольные вещи. Вот что произошло.

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

От осознания своей некомпетентности и неспособности в логику? Ну да, не повезло, бывает. А зачем ты рассказываешь об этом и пытаешься строить из себя кого-то?

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

Нет, произошло не это. Билд-машина запускает произвольный исполняемый файл, который делает произвольные вещи. Вот что произошло.

Ну в посте написано даже:

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

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

Пара кавычек не в том месте, из тестового бинарика выкалупывается ништячок,

Еще один дэ…

Какие «пара кавычек», если билд машина и так даёт полный карт-бланш сборочной системе на любую трансформацию входных данных в выходные?

Там не надо ниоткуда «сбегать», чтобы получить возможность исполнения кода. Алё, Алёша.

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

Ну в посте написано даже:

Да, ровно это и написано.

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

Там не надо ниоткуда «сбегать», чтобы получить возможность исполнения кода

Ты не понимаешь кажется. Этот код читают люди. Если в meson напрограммировано sed "\$ a ${exploit}|" это вызовет много вопросов и подозрений. То же самое в m4 – обычный вторник.

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

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

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

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

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

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

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

Ну как бы так же можно сказать, что 486+VGA хватало для игры дум, а теперь вот киберпанк тормозит.

Да если бы только киберпанк тормозил. Сраный калькулятор на GTK4 тормозит, причём независимо от железа. Без дёрганий окошко отрезайсить тоже нельзя.

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

Это всё круто, но была куча довольно сложных в плане графики игр, которые без проблем делали софтварный рендеринг. Ну я не знаю, Unreal/UT и прочие игры на их движке типа Deus Ex. Ты сейчас реально хочешь сказать, что интерфейсы на GTK4 сложнее и потому требуют больше ресурсов чем рендеринг жопы Дентона в DX?

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

Прости, но после тейка «почему бы не написать cmake на cmake» я не знаю что можно добавить.

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

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

Да ты чё. Рассказывал про «в cmake нет проблем», отрицал что это свойство примитивности языка, а теперь начал повторять, то что было сказано мной ранее? Да ты гений.

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

Да ты чё. Рассказывал про «в cmake нет проблем», отрицал что это свойство примитивности языка, а теперь начал повторять, то что было сказано мной ранее? Да ты гений.

Что ты несешь вообще?

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

Это абсолютно не имеет никакого отношения к shell execution «из-за не той кавычки». Ты зачем-то придумал эту ерунду.

Что касается ЯП сборочной системы, то я выше писал:

Всю эту срань на m4 и cmake давно пора заменить на продуманное API/DSL на основе встраиваемого ЯП общего назначения – JS или Lua. Будет простейший бинарь с минимумом зависимостей сборки, возможностей которого хватит на следующие 30 лет с головой.

И не выписывать() вот() сраные() чудеса() на() cmake.

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

Всю эту срань на m4 и cmake давно пора заменить на продуманное API/DSL на основе встраиваемого ЯП общего назначения – JS или Lua. Будет простейший бинарь с минимумом зависимостей сборки, возможностей которого хватит на следующие 30 лет с головой.

meson

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

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

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

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

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

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

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

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

Совсем поломался? Слился - всё, успокойся и не заспамливай меня чушью. Спамить будешь когда найдёшь что возразить. С клоунадой не ко мне.

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

Совсем поломался? Слился - всё, успокойся и не заспамливай меня чушью. Спамить будешь когда найдёшь что возразить. С клоунадой не ко мне.

Так это ты мне пишешь, клоун.

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

Погоди, а Nix?

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

Он turing complete?

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

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

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

hateyoufeel ★★★★★
()

А представьте, если бы новость опубликовали сегодня )

baobab
()

я пробовал xz удалять…. и у меня перестал грузиться линапс. напишите коллективное письмо чтобы его выкинули из сборок

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

в линупсе же питон неофициальный системный язык

rtxtxtrx ★★
()

Добавьте что ли вот эту ссылку в новость, а то обсуждение ушло в какие-то дебри.

Obezyan
()

На всякий случай откатился

bad=`xz --version | head -n1 | grep -oP ' \d\..*$' | xargs`
good=`5.2.5`
mkdir -p ~/xz/$bad
mkdir -p ~/xz/$good

cd ~/xz/$bad
apt download liblzma5 liblzma-dev xz-utils liblzma5:i386 liblzma-dev:i386 xz-utils:i386

cd ~/xz/$good
apt download liblzma5=5.2.5-2ubuntu1 liblzma-dev=5.2.5-2ubuntu1 xz-utils=5.2.5-2ubuntu1 liblzma5:i386=5.2.5-2ubuntu1 liblzma-dev:i386=5.2.5-2ubuntu1 xz-utils:i386=5.2.5-2ubuntu1
sudo dpkg -i --force-all ./*.deb
Flashwalker
()

бэкдоры это хорошо, каждый день использую systemd и команду sudo *сарказм*

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

Да если бы только киберпанк тормозил. Сраный калькулятор на GTK4 тормозит, причём независимо от железа. Без дёрганий окошко отрезайсить тоже нельзя.

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

Вот, посмотри как это делалось в твоих хвалёных старых системах. Спойлер: никак. Если не делать ресайз и перетаскивание в рантайме то и дёргаться ничего не будет.

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

А вот и не пофикшено, так как фиксить было нечего.

Объясните тогда мне такую картину: https://mirror.yandex.ru/archlinux/iso/

Как мы знаем срезы выходят 1 числа, и пару дней назад там лежал 2024-03-01, тысячи людей брали этот iso и ставили с него (я молчу уже про то сколько обновлялись за этот месяц) а теперь хлоп. И он исчезает.

Почему ? Раз фиксить было нечего ?

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

И можно ли доверять Alexander E. Patrakov, Rein Fernhout и terraminator <terraminator () protonmail com> ?

(Вот думаю, переустанавливать ли все арчлинуксы? Или забить, всё равно нет гарантии, что у разработчиков всё чисто.)

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

Понимаете в чем дело ? В том что это все просто слова/текст без доказательств. А вот удаление образа 2024-03-01 с зеркал это конкретный ход. И если понять почему это сделано, можно ответить на многие вопросы.

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

Вполне можно объяснить перестраховкой.

Это объясняется только одним : сами до конца не понимают всей картины, вроде все ок, а может и нет. Такое объяснение только делает хуже.

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

Что значит «дёргаться»?

При корректной логике кода приложения ничего не дёргается. Совсем куку что ли?

Это в говнокоде зачастую навалено костылей, когда при ресайзе размеры отдельных элементов окна пересчитываются в несколько приёмов с рендерингом между ними, что приводит к видимому дёрганию layout-а.

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

На старых железках (кто в МС Офис работал во времена 1-х Пентиумов и Win95, тот помнит) перерисовка окна при ресайзе или при появлении окна из-под другого окна вообще могла быть видима вся как в слоумо, особенно если в системе мало ОЗУ.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.