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)
Ответ на: комментарий от gag

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

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

единственное, что спасёт Линукс — это Микрософт. Хорошие проприетарщики из Микрософта

так МС уже спасает Линукс, через раст.

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

В итоге, раньше программы на GTK быстро запускались, а теперь пока все эти шейдеры прокомпилируются.

Не, ну это косяк. Надо кешировать.

Я радовался про сам принцип: надо быть поближе к железу, убирая прослойки. OpenGL/Vulkan – ближе некуда, т.е. идеально.

А если cairo/skia/хз-кто-ещё полезен потому что умеет не только в примитивы, но и что-то такое, чего не умеет собственно вулкан, то это надо оформлять неинтрузивными хелперами, ни в коем случае не прогоняя через его фасад все вызовы вообще.

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

Geode как раз для встраиваемых систем. Но учитывая цену явно не для телеков.

Да, в итоге получается, что есть какая-то слабая железка но с OpenGL ES, на которой будет и вэйлэнд, и GTK 4. А есть вполне себе достаточные для работы ноуты и ПК, но в которых нет достаточно свежей OpenGL ES / 3+, не говоря уже о вулканах - и всё, приехали.

gag ★★★★★
()
Ответ на: комментарий от sunjob
  • тоже самое нельзя провернуть с «иными» популярными инструментами сборки?

Нельзя потому что все файлы включая файлы сборки генерируются на компьютере пользователя. Архив с исходниками представляет себя точную копию опрделённого коммита в системе контроля версий (Git и т.п.). А в системе контроля версий можно посмотреть историю изменений любого файла, включая описание сборки (Makefile, Cmakelists.txt, meson.build и т.п.).

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

А в архиве с исходниками не должно быть автосгенеренных файлов

И вот поэтому автоконф надо выкинуть на мороз. Всё правильно говоришь.

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

в ветке все ругают autotols/configure etc, видимо, все понимают чем они плохи. можно в 2-3 предложениях для простых людей обьяснить?!

спасибо

Автолулзы – набор костылей из 80х, который на 95% неактуален сегодня. Когда ты запускаешь скрипт ./configure, он проверяет в том числе что твой компилятор соответствует стандартам, у тебя есть стандартные заголовочные файлы и т.д. Штука в том, что компиляторы без этого всего сдохли лет 20-30 назад, и сегодня все эти проверки тупо неактуальны.

А на компах, где это было актуальным, ./configure тупо не запустится, потому что там нужен относительно свежий bash, да и сам размер этого скрипта приведёт к тому, что сборка затянется на часы. Типа, для относительно небольших проектов на C (в пределах 10к строк, например) ./configure занимает больше времени, чем собственно сама сборка проекта.

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

Ну и в среднем работает всё это примерно очень плохо.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от cvs-255

https://www.debian.org/devel/join/. Годами батрачат без статуса, на мэйнтейнеров. Потому что надо получить одобрение от лучше нескольких. Дальше https://wiki.debian.org/DebianMaintainer. Главное, это подпись твоего ключа. Вроде, это должно быть на сходке лично: https://wiki.debian.org/Keysigning.

А по-настоящему попытаться стать полноправным членом Debian: https://wiki.debian.org/DebianDeveloper.

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

А как ты его проверишь? «Не работаешь ли ты на АНБ, дружище?» «Нет, что вы!» «Ну ОК, подходишь нам».

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

Не, ну это косяк. Надо кешировать.

Да, но не в GTK:

А, значит, после того, как они сообщили это в mesa, их это больше не интересует, и баг закрыт. А в mesa совсем никуда не торопятся:

Вот так тривиальное кеширование оказывается сложной задачей.

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

Да, но не в GTK

А с точки зрения спецов по графическому стеку, кто на самом деле должен кешировать – mesa или gtk? На моё сугубо общефилософское ИМХО, с более низкоуровневыми инструментами и возни бывает поболее (типа как ручное управление памятью vs сборка мусора), а тут звучит так, что кто-то хочет и рыбку съесть, и жопу не ободрать.

(Хотя по твоей первой ссылке, где про show window performance, в одном из каментов речь идёт даже про компиляцию шейдеров, а тупо про их медленную загрузку. Забавно.)

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

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

Про bash – 4.2. Там всё под древнючий sh написано.

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

Я вообще не понимаю, зачем его используют ныне

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

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

Про bash – 4.2. Там всё под древнючий sh написано.

Серьёзно? У меня в каком-то проекте configure падал из-за не той версии bash как-то раз. Но яхз, глубоко не копал и уже не помню.

Один хрен, всё остальное гораздо большая проблема чем портировать bash.

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

Там ещё и меинтейнорм Дебиана один из ботов заделался.

Зарегистрировался на salsa.debian.org, что может сделать любой желающий, ≠ стал мейнтейнером.

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

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

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

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

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

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

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

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

На мой взгляд, кешировать должен специальный сервис, которому gtk должно передавать скомпиленные шейдеры. Например это может быть кеширование в видей файлов на диске, или в редисе, или где еще. Конкретный выбор должен определяться маинтайнерами дистра или сборки в зависимости от целевой системы и требований безопасности. Пихать это в мезу неправильно

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

Возможно, туда аффтар конкретного пакета накидал башизмов, когда configure.ac правил.

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

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

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

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

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

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

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

Писал.

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

Когда в Debian открывают баг, что с такой-то либой/программой что-то не так. То даже если дело не в опакечивании, а в апрстриме, то баг помечается, что перенаправлен по такому-то upstream URL. Но его нельзя закрыть, пока первопричина не будет исправлена. Так как пользователи Debian используют этот пакет и, в первую очередь, будут искать баг там (ну, хорошо, это немного идеализировано).

Т.е. сказать что баг в mesa, это просто, но, ведь, тормозят просто все GTK 4 программы. И приходить с рапортом будут именно к тебе в GTK, а ты такой, у нас всё в порядке, бага нет, это «ему не слышно». И, ведь, существует же механизм «blocked by».

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

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

Я тут процитирую товарища @shimon в очередной раз, который очень хорошо описал ситуацию с багами в Debian:

Хотя, вообще, у дебианщиков (да и многих других) несколько своеобразное представление о стабильности.

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

Иногда в порядке окучивания граблей грабли заменяют на противопехотные мины (кто помнит эпичнейший фейл с OpenSSL?). Конечно, конечно, хотели как лучше, чтоб от наступания не было больно...

Ну и что, что в других дистрибутивах грабли собрали комбайном? Что с того, что в других дистрибутивах уборка граблей стала процессом постоянным? Это ни черта не значит, ведь это нарушает стабильность. А тут поле с флажками, такое теплое, такое свое, прям как е#учий ЗиЛ «буханка», прости господи, мать твою через коромысло.

Тыц: XScreensaver может быть удалён из Debian (комментарий)

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

На всевозможных телеках opengl es используется для почти всего. (Кроме броадкомоских чипов, там своё апи)

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

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

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

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

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

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

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

Чисто формальные проверки, смотрят на адекватность. Возможно, ищут во всяких БД. В голову к человеку не залезть. А в опенсорсе даже не нужно никаких личных встреч.

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

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

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

только после двухнедельного совещания в рассылках

Не, ну по-разному бывает. Вот с xz мгновенно пересобрали в sid, и ещё не прошло и 11 часов, как уже пошло в testing.

кто помнит эпичнейший фейл с OpenSSL

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

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

Не совсем. Любой может зарегаться в дебиановском гитлабе и предлагать MRы. Еще можно залить пакет через mentors.debian.net, если найдешь дебиан разработчика (спонсора), который согласится залить твой пакет в репозиторий.

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

Слать патчи или, вот с переходом на gitlab и MR - это «authored by». Комитить и, таким образом, брать на себя ответственность могут только DM/DD.

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

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

Когда-нибудь я доберусь проверить этот тезис, написав десктопную софтину на ImGUI/Vulkan…

…Кстати! Проблема тормозов компиляции и/или загрузки шейдеров решается тривиально: отказом от оных. Или может cairo тоже шейдеры компилирует? А может тут просто горе от ума: шейдеры – это круто, надо заюзать:

Подошел я тут к тимлиду:
Надо нам внедрить блокчейн
Он, дурак, засомневался
говорит «А нам зачем?»
Как зачем, ведь это модно!

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

Jinja придумали специально для этого. Хочется экзотики — parser Лебедева.

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

В шейдерах как раз и реализован код для графических ускорителей - не откажешься. В cairo его, соответственно нет. Точнее был экспериментальный бэкэнд для OpenGL, но его не допилили, а недавно GTK-шник и выкинул.

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

В смысле «не откажешься»? Нынче что, уже нельзя использовать древнее до-шейдерное API рисования примитивов? Только в шейдеры его запихивать и потом их вызывать? Не верю. Qt, опять же, юзает EGL бакенд – и вполне себе шустро работает.

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

Вот товарищ Hans Jansen завел баг, подготовил фикс для него и выложил на mentors. DD Sebastian Andrzej Siewior подписал это и залил в репозиторий. Соответсвенно, любой Василий имеет шансы протолкнуть свой код в репозиторий. И не так уж и важно, кто в итоге нажмет кнопку «Upload».

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

Заливать свои предложения - это одно. Ответственность перенимает тот, кто жмёт коммит непосредственно в Debian. Шансы протолкнуть это да, так работает свободное ПО.

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

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

Да, нельзя. Fixed pipeline уже не поддерживается на аппаратном уровне, а старые API без шейдеров всё равно работают через шейдеры, но внутри реализации Mesa и прочих драйверов.

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

Теперь в треде воняет PHP. Молодец.

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