Здравствуйте, netch80, Вы писали:

n> Ожидаю, что все расслабятся и будут надеяться на соседа.

n> Схема красивая, в месяц по ложечке.

Случайно обнаружили. Просто повезло.

https://boehs.org/node/everything-i-know-about-the-xz-backdoor

В прошлые разы спрашивали "ну где тот миллион глаз который высмотрит всё?"

В этот — не успело попасть в реальные дистрибутивы, даже в большинство unstable, уже нашёлся, кто спалил пятилетнюю подготовку.

Ожидаю, что все расслабятся и будут надеяться на соседа.

Схема красивая, в месяц по ложечке.

__>С одной стороны, да, но не совсем да. Мы как-то разрабатывали телеметрию, не скажу чего. Так вот, ревьюили реквесты в основном я и другой разраб. Остальные никогда никаких вопросов не задавали. Теоретически можно было бы договориться и закоммитить пропуск какой-нибудь проверки.

Безо всяких теорий, я тебе так скажу — коммит с бинарным архивом для тестов прошел бы на ура.

Отдельно прошел бы коммит с тем самым скриптом для m4 — ибо их ревьювить невозможно от слова вообще.

И уж тем более там никакой пентестинг бы не помог — ибо, чтобы он помог, нужно знать, что искать, где искать, и как.

Я все-таки не зря в области (сетевой) безопасности почти 10 лет работал. Шутка ли, в 2000 году начинал с файрволла под windows 95/98 Как же давно это было. Так вот, вставить бэкдор в закрытый копроративный код _В СРЕДНЕМ_ на два порядка проще, чем во что-то, находящееся в поле зрения экспертов из разных организаций. Иными словами, куда меньше шансов встретить бэкдор в sshd, чем в каком-нибудь корпоративном форке оного. Если что, корпорации в курсе про это

Здравствуйте, netch80, Вы писали:

N>В прошлые разы спрашивали "ну где тот миллион глаз который высмотрит всё?"
Так и где эти глаза?

Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc.
Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol
Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

Найдено то совсем не анализом кода а дебагом вылезшей проблемы.
В этом случае наличие сурсов процесс дебага конечно упрощает но не является критичным.
После чего собственно и начали пристально смотреть на конкретный кусок кода.
До этого "миллионы мух" как то не особо беспокоились.

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

N>Схема красивая, в месяц по ложечке.
Так оно и делается, да.
OpenSource по определению особенно vulnerable к таким атакам

Здравствуйте, netch80, Вы писали:

N>В прошлые разы спрашивали "ну где тот миллион глаз который высмотрит всё?"

Что я понял (поправьте если не так):
а. Бэкдор попал в несколько дистрибов
б. Был обнаружен случайно. Если бы не его прожорливость, то и мысли что-то там искать ни у кого бы не возникло
в. Был обнаружен пользователем, т.е. человеком не связанным с проектом
Но по итогу — ура опенсорсу?

Здравствуйте, Pzz, Вы писали:

Pzz>Вообще, это круто. Библиотека, которая входит примерно во все критические системные демоны с сетью, ее пишет черти кто, и никому до этого воообще нет дела.

Ты описал текущее состояние IT сферы в целом

Здравствуйте, CreatorCray, Вы писали:

CC> M> Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью?

CC> У нас такое QA отловил бы, ещё до того как интеграторы пустили бы это в master

Павлин, говоришь... https://ru.wikipedia.org/wiki/%D0%91%D1%8D%D0%BA%D0%B4%D0%BE%D1%80#%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2_%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B0_%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8_%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D0%B2_TLS_%D0%BE%D1%82_%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D0%B8_Apple

Здравствуйте, netch80, Вы писали:

Pzz>>По итогу ппц полный. Эту дырку случайно нашли. Интересно, сколько их не нашли?

N>Главное, какие выводы сделали для будущего процесса. По крайней мере редхат должен запустить процесс начальной ревизии всех зависимостей и перепроверку "по крону".
N>А в коллекции примеров для обучения появился роскошнейший пример.

Я думаю, такое очень сложно найти. Можно поймать при внимательном ревью новых коммитов (да кто ж его делает-то, это внимательное ревью?), а вот в уже существующих пакетах — вряд ли.

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

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

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

Pzz>>Вообще, это круто. Библиотека, которая входит примерно во все критические системные демоны с сетью, ее пишет черти кто, и никому до этого воообще нет дела.

N>Не в наезд: "чёрт-те кто".

Вот черти вот и пишут

Здравствуйте, netch80, Вы писали:

N>https://boehs.org/node/everything-i-know-about-the-xz-backdoor

Thanks? They also banned the repository, meaning people can no longer audit the changes made to it without resorting to mirrors. Immensely helpful, GitHub. They also suspended Lasse Collin’s account, which is completely disgraceful.

Мде.

Здравствуйте, CreatorCray, Вы писали:

N>>Схема красивая, в месяц по ложечке.
CC>Так оно и делается, да.
CC>OpenSource по определению особенно vulnerable к таким атакам

Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно сделать вообще все, что угодно в гораздо более сжатые сроки.

Вообще, очень основательно прорабатывали. Выбрали проект с одним мейнтейнером, применяли social engineering и т.п. Причем, пришлось идти на заметные red flags — бинарные тестовые файлы в репе или замену safe функций на unsafe

Здравствуйте, landerhigh, Вы писали:


L>>>Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно сделать вообще все, что угодно в гораздо более сжатые сроки.
SK>>Это атака не против source, а против конкретного пользователя.

L>Пока что выглядит так, что это была хорошо спланированная и серьезно огранизованная почти успешная попытка внедрить бекдор на (почти) каждый компьютер с Linux. Организация, располагющая такими ресурсами, скорее всего, производителя ПО с закрытым кодом может просто убедительно попросить добавить такой бекдор.

Какими "такими" ресурсами? непосредственно наследил один неизвестный с нескольких аккаунтов. код с багами и не оттестирован.

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

L>>>Вообще, очень основательно прорабатывали. Выбрали проект с одним мейнтейнером, применяли social engineering и т.п. Причем, пришлось идти на заметные red flags — бинарные тестовые файлы в репе или замену safe функций на unsafe

SK>>Но попались то они не на этом.

L>При этом то, что source был таки open, сильно помогло в раскрытии замысла.

"Раскрытие замысла", это его предотвращение _до_ совершения. А тут расследование постфактум, уже свершенного. Исходники просто незначительно облегчили работу.

Все проблемы от жадности и глупости

Здравствуйте, landerhigh, Вы писали:


L>Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно сделать вообще все, что угодно в гораздо более сжатые сроки.

Это атака не против source, а против конкретного пользователя.

L>Вообще, очень основательно прорабатывали. Выбрали проект с одним мейнтейнером, применяли social engineering и т.п. Причем, пришлось идти на заметные red flags — бинарные тестовые файлы в репе или замену safe функций на unsafe

Но попались то они не на этом.

Все проблемы от жадности и глупости

Здравствуйте, landerhigh, Вы писали:


L>Вообще, очень основательно прорабатывали. Выбрали проект с одним мейнтейнером, применяли social engineering и т.п. Причем, пришлось идти на заметные red flags — бинарные тестовые файлы в репе или замену safe функций на unsafe

Эти бинарные файлы выглядели очень оправданными — тестовые примеры архивов. В том числе пример битого архива, где и сидел код. Как они вообще могут быть небинарными?

Надо сказать задумка на грани гениальности. Это ж надо придумать поместить код в битый архив. Битый! Который исподтишка восстанавливается системой сборки. И потом заботливо все символы преобразовали так, чтобы в явном виде нигде не вылезали текстовые строки API-функций, используемых для внедрения в sshd и работы. Собственно на этом и погорели в итоге — маскировка слишком медленно работала.

Здравствуйте, CreatorCray, Вы писали:

CC>Найдено то совсем не анализом кода а дебагом вылезшей проблемы.
CC>В этом случае наличие сурсов процесс дебага конечно упрощает но не является критичным.
CC>После чего собственно и начали пристально смотреть на конкретный кусок кода.
CC>До этого "миллионы мух" как то не особо беспокоились.

Так или иначе, но побеспокоились. И без открытых исходников было бы все намного проще, а так пришлось очень хитрым образом прятать закладку. А с закрытыми вообще до конца неясно, что софт делает с данными юзера, что может и не может слить в телеметрии.

Здравствуйте, Stanislaw K, Вы писали:

L>>Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно сделать вообще все, что угодно в гораздо более сжатые сроки.
SK>Это атака не против source, а против конкретного пользователя.

Пока что выглядит так, что это была хорошо спланированная и серьезно огранизованная почти успешная попытка внедрить бекдор на (почти) каждый компьютер с Linux. Организация, располагющая такими ресурсами, скорее всего, производителя ПО с закрытым кодом может просто убедительно попросить добавить такой бекдор.

L>>Вообще, очень основательно прорабатывали. Выбрали проект с одним мейнтейнером, применяли social engineering и т.п. Причем, пришлось идти на заметные red flags — бинарные тестовые файлы в репе или замену safe функций на unsafe

SK>Но попались то они не на этом.

При этом то, что source был таки open, сильно помогло в раскрытии замысла.

Здравствуйте, landerhigh, Вы писали:

L>Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно ...
... громко пёрнуть в лужу, ибо в closed source так легко что либо добавить не получится.

Здравствуйте, netch80, Вы писали:

N>В прошлые разы спрашивали "ну где тот миллион глаз который высмотрит всё?"

Что самое ржачное в этой истории: Andres Freund, первым это обнаруживший, работаат в MSFT

Здравствуйте, CreatorCray, Вы писали:

N>>Схема красивая, в месяц по ложечке.
CC>Так оно и делается, да.
CC>OpenSource по определению особенно vulnerable к таким атакам

Можно подумать, в closed source кто-то вообще смотрит на вносимые изменения (про code review в курсе, но сильно сомневаюсь, что в корпорации, где все заняты своими тикетами, кто-то будет действительно внимательно смотреть на чужие изменения).

Здравствуйте, rFLY, Вы писали:

FLY>Но по итогу — ура опенсорсу?

По итогу ппц полный. Эту дырку случайно нашли. Интересно, сколько их не нашли?

Вообще, это круто. Библиотека, которая входит примерно во все критические системные демоны с сетью, ее пишет черти кто, и никому до этого воообще нет дела.

CC>... громко пёрнуть в лужу, ибо в closed source так легко что либо добавить не получится.

Там намного проще. В тысячи раз. Без вариантов. Достаточно одному создать реквест, второму принять, — и все, у всех юзеров теперь бэкдор.

Здравствуйте, CreatorCray, Вы писали:

M>> И без открытых исходников было бы все намного проще
CC>Как ты себе представляешь добавление подобного в закрытые исходники со стороны?

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

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, landerhigh, Вы писали:

L>>Если ресурсы, которые были затрачены на эту атаку, нацелить на closed source, то можно ...
CC>... громко пёрнуть в лужу,

Ты это только что сделал.

CC> ибо в closed source так легко что либо добавить не получится.

Если бы я был похожим диверсантом, я на одном из последних проектов (извини, детали скрыты) мог бы аналогичной техникой добавить закладки в связное оборудование, работающее у нескольких миллионов(!) клиентов, и никто бы ничего не заметил, потому что все перегружены, чистки и перепроверки кода нет в принципе, ревью делается по принципу "ну примерно похоже на тему, тесты 1-го и 2-го уровня важности прошли, регрессий нет, а дальше хоть трава не расти", а хоть какой-то общей "экспертизой" в теме обладает только шеф 2-го уровня, который по своей должности 90% времени проводит в совещаниях с пустоголовыми коллегами из нетехнических отделов. Выяснение, где же проблема, заняло бы год, а устранение закладки с учётом того, как происходит продвижение чего угодно кроме горящей вот сейчас фичи — ещё год. Контора, скорее всего, обанкротилась бы. Против такого защитило бы только одно — неохота физически получать паяльник в зад (но для эксплойтов такого масштаба смена страны и паспорта окупилась бы).

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

Верю, что ты думаешь, что везде такой же порядок, как в твоём отделе. Но ты явно чего-то не знаешь про свой отдел

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

Э, с этим надо осторожнее, а то всякие трехбуквенные агентства могут и не понять рвения

Здравствуйте, Sharov, Вы писали:

S>Дурацкий вопрос, а где это можно глянуть?

Я смотрел на живой системе версию пакета.

__>Генту не нужна никому, кроме малолетних красноглазиков, и после этой диверсии они не пострадали, потому что никаким хакерам они не интересны.

Ну да, среди условий внедрения там:

Running as part of a debian or RPM package build:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

Но это скорее всего связано с другим:

openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.

	хук RSA_public_decrypt
	Notably liblzma's symbols are resolved before many of the other libraries, including the symbols in the main sshd binary. This is important because symbols are resolved, the GOT gets remapped read-only thanks to -Wl,-z,relro. To be able to resolve symbols in libraries that have not yet loaded, the backdoor installs an audit hook into the dynamic linker, which can be observed with gdb using watch _rtld_global_ro._dl_naudit It looks like the audit hook is only installed for the main binary. That hook gets called, from _dl_audit_symbind, for numerous symbols in the main binary. It appears to wait for "RSA_public_decrypt@....plt" to be resolved. When called for that symbol, the backdoor changes the value of RSA_public_decrypt@....plt to point to its own code. It does not do this via the audit hook mechanism, but outside of it.

Но в любом случае версии >=5.6.0 в Gentoo тоже уже "замаскировали"
https://bugs.gentoo.org/928134#c2

Здравствуйте, Michael7, Вы писали:

M>Эти бинарные файлы выглядели очень оправданными — тестовые примеры архивов. В том числе пример битого архива, где и сидел код. Как они вообще могут быть небинарными?

Битый архив можно, а скорее, нужно, генерировать при запуске тестов.

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

M>Надо сказать задумка на грани гениальности. Это ж надо придумать поместить код в битый архив. Битый! Который исподтишка восстанавливается системой сборки. И потом заботливо все символы преобразовали так, чтобы в явном виде нигде не вылезали текстовые строки API-функций, используемых для внедрения в sshd и работы. Собственно на этом и погорели в итоге — маскировка слишком медленно работала.

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

Здравствуйте, CreatorCray, Вы писали:

L>>Организация, располагющая такими ресурсами
CC>
CC>Какими ресурсами?


Exhibit 1:

	Скрытый текст

Атаку детально прорабатывали минимум три года.
Можно, конечно, предполагать, что это дело рук одиночки, а то и самого единственного мейнтейнера, который этим хотел [подставить по вкусу]

Но как-то слабо верится. Особенно если у человека есть основная работа и вообще жизнь.


L>> скорее всего, производителя ПО с закрытым кодом может просто убедительно попросить добавить такой бекдор.
CC>Будет послана нахрен,

А если посылалка не отросла?

CC>ибо никто не будет хоронить свою репутацию,

Примеров, когда компании хоронят свою репутацию абсолютно добровольно, более чем хватает.

CC>на которой базируются ежегодные продажи, ради смешной суммы, которая тут была потрачена.

У тебя включен режим повышенной наивности. Разве кто-то упоминал деньги?

L>>При этом то, что source был таки open, сильно помогло в раскрытии замысла.
CC>Не. Разница довольно таки незначительная.

Ну да

Здравствуйте, landerhigh, Вы писали:


L>Атаку детально прорабатывали минимум три года.
L>Можно, конечно, предполагать, что это дело рук одиночки, а то и самого единственного мейнтейнера, который этим хотел [подставить по вкусу]
L>Но как-то слабо верится. Особенно если у человека есть основная работа и вообще жизнь.
А что ты в этом видишь сложного или трудоемкого? По мне, так самое сложное в этой цепочке было стать майнтейнером.

Здравствуйте, Stanislaw K, Вы писали:

SK>Какими "такими" ресурсами? непосредственно наследил один неизвестный с нескольких аккаунтов. код с багами и не оттестирован.

Атака в активной фазе продолжалась три года. Кто знает сколько времени она планировалась. Мне сложно поверить в то, что один исполнитель просто прикола ради (или по каким-то другим личным причинам) будет скрупулезно продолжать операцию.

SK>Мне кажется, я даже уверен, у организации (с ресурсами) и неизвестных исполнителей было бы больше и код оттестирован в лабе и бы изменения коллективно внесли бы быстрее.

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

SK>И фиг бы вообще тысячи глаз его заметили, как это было в те разы.

Так часть эксплойта заботливо спрятали от "тысяч глаз":

The m4 modification was only made in the github tarball, somewhat later, and it's not checked into git.

Оно там обфуцировано, конечно, но все же.

L>>При этом то, что source был таки open, сильно помогло в раскрытии замысла.
SK>"Раскрытие замысла", это его предотвращение _до_ совершения.

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

SK>А тут расследование постфактум, уже свершенного. Исходники просто незначительно облегчили работу.

Значительно — виртуальная личность "злоумышленника" уже известна. В случае с ПО с закрытым кодом концы можно запрятать.


Впрочем, я могу бредить и все это — дипломная работа студента по специальности "кибербезопасность". Или научное исследование, привзанное показать, что любой процесс может скомпрометирован применением social engineering.

Здравствуйте, landerhigh, Вы писали:

L>Время. Исхожу из предположения, что у человека, способного такое спланировать в одиночку, без дополнительной мотивации на подобные шалости просто не будет времени.
Да какие шалости, понятно что хотел заработать либо сам, на эксплуатации уязвимости, либо продать ее.

L>А тут нужно было быть активным мейнтейнером, код коммитить и т.п.
Если это устоявшаяся библиотека, то не думаю, что часто приходилось что-то добавлять или изменять.

Здравствуйте, CreatorCray, Вы писали:


M>>Так или иначе, но побеспокоились.
CC>Миллионы мух на ревью кода ничегошеньки не заметили.

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

M>> И без открытых исходников было бы все намного проще
CC>Как ты себе представляешь добавление подобного в закрытые исходники со стороны?

Устроиться на работу, получить права на коммиты. Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью? Это одна сторона вопроса, другая, что с точки зрения юзера вообще непонятно, что из его данных в каких объемах сливается или может быть слито при каких условиях и кому.

Здравствуйте, Michael7, Вы писали:

M>Задумано было красиво, что ни говори.
+1

M>Устроиться на работу, получить права на коммиты.
Надо пройти все интервью, засветив себя реального, устроиться, на в нужный подотдел, получить доступ в нужную репу...

M> Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью?
У нас такое QA отловил бы, ещё до того как интеграторы пустили бы это в master

M>с точки зрения юзера вообще непонятно, что из его данных в каких объемах сливается или может быть слито при каких условиях и кому.
Опять эти байки.
Юзер ни ухом ни рылом что тут что там.
Да и в целом никто не читает все сурсы того, что он себе тока шо поставил.

Здравствуйте, CreatorCray, Вы писали:

CC>OpenSource по определению особенно vulnerable к таким атакам
А кто не особенно? В гугле и фейсбуке норм тема аппрувить коммиты друг друга. Я видел как два китаца таким образом затащили лютый говнокод в фейсбучную монорепу.

Здравствуйте, CreatorCray, Вы писали:

L>>Атака в активной фазе продолжалась три года.
CC>Подавляющее время ничего не происходило. Над было просто выжидать и писать письма имитируя гневных пользователей, требующих поскорее "принять патч который им нужен"

Да, как два пальца ап асфальт.

L>> Кто знает сколько времени она планировалась.
CC>Какое это имеет отношение к требуемым ресурсам?

Самое прямое

L>> Мне сложно поверить в то, что один исполнитель просто прикола ради (или по каким-то другим личным причинам) будет скрупулезно продолжать операцию.
CC>А что тут было такого, что не может провернуть один чел с целью и лёгким аутизмом?

Тем, что это не Голливуд, например.

L>>Значительно — виртуальная личность "злоумышленника" уже известна.
CC>И как это поможет? Виртуал этож как презерватив, порвался — выкинули.

Тем, что в случае с closed source концы можно надежно спрятать так, что разматывать будет вообще нечего.

L>> В случае с ПО с закрытым кодом концы можно запрятать.
CC>Чтоб что то в закрытый софт добавить надо устроиться в компанию работать и внутри получить доступ к коду конкретной подсистемы.
CC>Виртуалом это не получится.

В тебе говорит некоторая наивность.

Здравствуйте, CreatorCray, Вы писали:

M>>Устроиться на работу, получить права на коммиты.
CC>Надо пройти все интервью, засветив себя реального, устроиться, на в нужный подотдел, получить доступ в нужную репу...

Вы как маленькие.
Есть же люди, которые уже все прошли. Нужно просто выбрать наиболее мотивированного сотрудника. Или мотивировать его. Деньгами. Или фотографиями.

M>> Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью?
CC>У нас такое QA отловил бы, ещё до того как интеграторы пустили бы это в master

Рассказать, как спрятать такое от QA и вообще внутренней верификации?

CC>У нас такое QA отловил бы, ещё до того как интеграторы пустили бы это в master

давай не будем про ваше QA
Они бы вообще ничего не заметили.

Здравствуйте, landerhigh, Вы писали:

L>Замечу, что без m4 файла, который отличался от того, что в репозитории, внедрение не работает. Но, как пишут, то, что содержание таболла для сборки зачастую отличается от репы, и это принятая практика(!). То есть есть уявзимость собственно в процессе.

Ну обычно таки тарболл отличается предсказуемо. Например, один из частых вариантов — в тарболле выполнен autogen.sh с конкретной версией autotools и соответственно уже есть готовый configure, а в репе — нет. Разумеется, для проверки надо сверить, что генерируется именно этот configure, а не отличающийся на 1-2 очень интересных строчки.
Тут же вынуждены были это нарушить. Могли постараться получше, конечно, но поймали совсем не на этом...

Один знакомый ещё в 98-м рассказывал, как писали софт под игровые автоматы. Комиссия проверяла, что генерируется именно тот выходной бинарь, что им подаётся на тест, из всех исходников. А gcc тогда писал таймстамп компиляции, и ему это явно отрубали. Потом перестал (не из-за этих, а из-за требования повторяемости сборки в OBS и аналогах от RH), стало легче. Вот такие методы желательно было бы иметь везде.

SK>>Нужно еще заставить линуксоидов массово пользоваться этим закрытым ПО.
L>Хватит уже про "линуксоидов". Линукс сейчас вообще везде. Даже в утюгах, без преувеличения.

+100%.

Здравствуйте, student__, Вы писали:

__>С одной стороны, да, но не совсем да. Мы как-то разрабатывали телеметрию, не скажу чего. Так вот, ревьюили реквесты в основном я и другой разраб. Остальные никогда никаких вопросов не задавали.

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

__>Теоретически можно было бы договориться и закоммитить пропуск какой-нибудь проверки.

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

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

А если бы было сделано чуть похитрее, и результаты верификации подписи не всегда игнорировались, а только при определенных обстоятельствах? Или, так в цифровой подписи довольно много проверок, если бы не все из них осуществлялись корректно, оставляя умелым и сведущим ручкам возможность подсунуть невалидную подпись?

Какой шанс, что при хорошей маскировке пентестеры на это бы нарвались?

Здравствуйте, netch80, Вы писали:

N>Схема красивая, в месяц по ложечке.

После этой новости слова Дурова про "приглашали к себе, интересовались, какие open source библиотеки используем, предлагали использовать какие-то конкретные открытые проекты" воспринимается совсем иначе =)

N>В этот — не успело попасть в реальные дистрибутивы, даже в большинство unstable, уже нашёлся, кто спалил пятилетнюю подготовку.

Успело-успело, в тот же Gentoo 24 февраля добавили версию 5.6.0 как нестабильную, а 9 марта заменили на 5.6.1 и 24 марта пометили как стабильную.

N>Ожидаю, что все расслабятся и будут надеяться на соседа.

А может наоборот, повод к тому чтобы MS "закрутил гайки" и ввел KYC или что-то типа того, чтобы всякие анонимусы в майнтейнеры не просачивались.

N>Схема красивая, в месяц по ложечке.

И спрятано затейливо в тестовый файл, на котором архивация проверяется.
А само внедрение на этапе сборки и код внедрения отсутствует в source control, но присутствует только в аривах выложенных майнтейнером-злоумышленником.

Здравствуйте, m2user, Вы писали:

M>Успело-успело, в тот же Gentoo

Генту не нужна никому, кроме малолетних красноглазиков, и после этой диверсии они не пострадали, потому что никаким хакерам они не интересны.

Здравствуйте, Alekzander, Вы писали:

A>Мде.

Думается что закрыли доступ к репе чтоб не растаскивали backdoor по другим репам, уменьшив масштабы "заражения". Так что тут более менее понятно rationale.
А вот почему засуспендили этого чувака — хз, возможно просто сгоряча подмели вообще всех кто там засветился.

Здравствуйте, CreatorCray, Вы писали:

CC>Думается что закрыли доступ к репе чтоб не растаскивали backdoor по другим репам

З — Забота

Здравствуйте, Alekzander, Вы писали:

CC>>Думается что закрыли доступ к репе чтоб не растаскивали backdoor по другим репам
A>З — Забота

Ну в данном случае довольно логично перекрыть канал распространения чтоб потом не вычищать это говно по всему интернету.

Здравствуйте, landerhigh, Вы писали:

L>Организация, располагющая такими ресурсами

Какими ресурсами?

L> скорее всего, производителя ПО с закрытым кодом может просто убедительно попросить добавить такой бекдор.
Будет послана нахрен, ибо никто не будет хоронить свою репутацию, на которой базируются ежегодные продажи, ради смешной суммы, которая тут была потрачена.

L>При этом то, что source был таки open, сильно помогло в раскрытии замысла.
Не. Разница довольно таки незначительная.

Здравствуйте, Michael7, Вы писали:

M>Так или иначе, но побеспокоились.
Миллионы мух на ревью кода ничегошеньки не заметили.

M> И без открытых исходников было бы все намного проще
Как ты себе представляешь добавление подобного в закрытые исходники со стороны?

M>И потом заботливо все символы преобразовали так, чтобы в явном виде нигде не вылезали текстовые строки API-функций, используемых для внедрения в sshd и работы. Собственно на этом и погорели в итоге — маскировка слишком медленно работала.

Спалились на неумении писать компактный код. Вот если б там весь код был пару килобайт (а ведь больше-то и не надо!), хрена бы кто заметил.

Здравствуйте, rFLY, Вы писали:

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

Время. Исхожу из предположения, что у человека, способного такое спланировать в одиночку, без дополнительной мотивации на подобные шалости просто не будет времени.
А тут нужно было быть активным мейнтейнером, код коммитить и т.п.

Здравствуйте, landerhigh, Вы писали:

L>Ощущение, что либо поторопились, либо недотестировали, либо банально экспертизы хватило только на социальную инженерию и обфускацию. Почти удалось внедрить бекдор, который можно было внезапно активировать.

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

Здравствуйте, landerhigh, Вы писали:

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

L> Кто знает сколько времени она планировалась.
Какое это имеет отношение к требуемым ресурсам?

L> Мне сложно поверить в то, что один исполнитель просто прикола ради (или по каким-то другим личным причинам) будет скрупулезно продолжать операцию.
А что тут было такого, что не может провернуть один чел с целью и лёгким аутизмом?

L>Значительно — виртуальная личность "злоумышленника" уже известна.
И как это поможет? Виртуал этож как презерватив, порвался — выкинули.

L> В случае с ПО с закрытым кодом концы можно запрятать.
Чтоб что то в закрытый софт добавить надо устроиться в компанию работать и внутри получить доступ к коду конкретной подсистемы.
Виртуалом это не получится.

Здравствуйте, landerhigh, Вы писали:

CC>>Какими ресурсами?
L>Image: XZ-backdoor.png
А где там про ресурсы, которые понадобились атакующему?

L>Атаку детально прорабатывали минимум три года.
Ты часом не путаешь "прорабатывали" и "реализовывали"?

L>Но как-то слабо верится. Особенно если у человека есть основная работа и вообще жизнь.
Вообще не вижу проблемы.

CC>>Будет послана нахрен,
L>А если посылалка не отросла?
Ну вон Apple регулярно посылает.

CC>>ибо никто не будет хоронить свою репутацию,
L>Примеров, когда компании хоронят свою репутацию абсолютно добровольно, более чем хватает.
Например? Только релевантное обсуждаемому раскладу "заставили" а не просто тупорылые решения верхнего манагемента.

L>У тебя включен режим повышенной наивности.
У меня всегда включен режим циничности.

L>Разве кто-то упоминал деньги?
Основная цель любой коммерческой компании — зарабатывание денег.

Здравствуйте, Michael7, Вы писали:

L>>Ощущение, что либо поторопились, либо недотестировали, либо банально экспертизы хватило только на социальную инженерию и обфускацию. Почти удалось внедрить бекдор, который можно было внезапно активировать.
M>Еще не расчитывали на "психа", которого стала раздражать полусекундная(!) задержка при авторизации, причем настолько, что он полез разбираться из-за чего она, правда думая не на бекдор, а просто на говнокодинг.

Прошляпили "задержку". Это косвенно говорит в пользу теории, что внедрение бекдора и сам бекдор делали разные люди, причем авторы кода бекдора вообще были не в курсе.

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

Здравствуйте, netch80, Вы писали:

N>В прошлые разы спрашивали "ну где тот миллион глаз который высмотрит всё?"
N>Ожидаю, что все расслабятся и будут надеяться на соседа.

Времена "all bugs are shallow" давно прошли. Даже Линус ничего не смог сказать, когда SJW его "на место поставили".

Здравствуйте, landerhigh, Вы писали:

SK>>Какими "такими" ресурсами? непосредственно наследил один неизвестный с нескольких аккаунтов. код с багами и не оттестирован.

L>Атака в активной фазе продолжалась три года.

Скорее полтора, но не больше двух.

L>Кто знает сколько времени она планировалась. Мне сложно поверить в то, что один исполнитель просто прикола ради (или по каким-то другим личным причинам) будет скрупулезно продолжать операцию.

Мне сложно представить что организация годами будет тратить деньги за иллюзорную возможность в отдаленном будущем.

SK>>Мне кажется, я даже уверен, у организации (с ресурсами) и неизвестных исполнителей было бы больше и код оттестирован в лабе и бы изменения коллективно внесли бы быстрее.

L>Я вот не уверен. весьма вероятно, что за механизм внедрения бекдора и за код собственно бекдора отвечали совершенно разные люди. Причем, последние вообще могли не знать, в чем именно принимауют участие, а круг первых должен быть ограничен и в идеале состоять только из одного человека.

Если верить интернет экспертам, собственно бэкдор примитивный, и даже "заморочное" скрытие бэкдора уровня школьника познавшего uuencode\base64.

SK>>И фиг бы вообще тысячи глаз его заметили, как это было в те разы.

L>Так часть эксплойта заботливо спрятали от "тысяч глаз":
L>

L>The m4 modification was only made in the github tarball, somewhat later, and it's not checked into git.

L>Оно там обфуцировано, конечно, но все же.

зипованный бинарник "закодированный" uuencode в текстовые файлы и собираемый из фрагментов. это поможет пройти автоматические анализаторы, но настолько необычно что должно привлекать внимание "тысячи глаз" как красная тряпка.

L>>>При этом то, что source был таки open, сильно помогло в раскрытии замысла.
SK>>"Раскрытие замысла", это его предотвращение _до_ совершения.

L>Ну, я бы не был так категоричен. Бекдор успел попасть только на отедьные ветки отдельных дистрибутивов. Если цель замысла была — каждому линуксу по бекдору, то вышел облом.
L>Правда, замысел мог быть в чем-то совсем другом.

Это возможно.

Например, теперь свободолюбивые анонимные хомячки будут добровольно показывать свои ID перед входом в интернет

SK>>А тут расследование постфактум, уже свершенного. Исходники просто незначительно облегчили работу.
L>Значительно — виртуальная личность "злоумышленника" уже известна. В случае с ПО с закрытым кодом концы можно запрятать.

Нужно еще заставить линуксоидов массово пользоваться этим закрытым ПО.

Все проблемы от жадности и глупости

Здравствуйте, rFLY, Вы писали:

FLY>Что я понял (поправьте если не так):
FLY>а. Бэкдор попал в несколько дистрибов
FLY>б. Был обнаружен случайно. Если бы не его прожорливость, то и мысли что-то там искать ни у кого бы не возникло
FLY>в. Был обнаружен пользователем, т.е. человеком не связанным с проектом

Всё верно.

FLY>Но по итогу — ура опенсорсу?

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

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

L>>Атака в активной фазе продолжалась три года.
SK>Скорее полтора, но не больше двух.

Аккаунт на гитхабе был создан в 21 году. Это уже активная фаза операции.

L>>Кто знает сколько времени она планировалась. Мне сложно поверить в то, что один исполнитель просто прикола ради (или по каким-то другим личным причинам) будет скрупулезно продолжать операцию.
SK>Мне сложно представить что организация годами будет тратить деньги за иллюзорную возможность в отдаленном будущем.

"Организации", о которых идет речь, операции прорабатвают десятилетиями.

L>>Я вот не уверен. весьма вероятно, что за механизм внедрения бекдора и за код собственно бекдора отвечали совершенно разные люди. Причем, последние вообще могли не знать, в чем именно принимауют участие, а круг первых должен быть ограничен и в идеале состоять только из одного человека.

SK>Если верить интернет экспертам, собственно бэкдор примитивный, и даже "заморочное" скрытие бэкдора уровня школьника познавшего uuencode\base64.

Еще вчера вечером были известны только общие детали работы бекдора.
А вот механизм внедрения с возможностью расширения — явно не уровня школьника.

SK>зипованный бинарник "закодированный" uuencode в текстовые файлы и собираемый из фрагментов. это поможет пройти автоматические анализаторы, но настолько необычно что должно привлекать внимание "тысячи глаз" как красная тряпка.

Этот бинарник был добавлен как "сломаный архив для тестов". А проверять, чем там в итоге make занимается никаких тысяч глаз не хватит.
Замечу, что без m4 файла, который отличался от того, что в репозитории, внедрение не работает. Но, как пишут, то, что содержание таболла для сборки зачастую отличается от репы, и это принятая практика(!). То есть есть уявзимость собственно в процессе.

SK>Нужно еще заставить линуксоидов массово пользоваться этим закрытым ПО.

Хватит уже про "линуксоидов". Линукс сейчас вообще везде. Даже в утюгах, без преувеличения.

Здравствуйте, CreatorCray, Вы писали:

CC>>>Будет послана нахрен,
L>>А если посылалка не отросла?
CC>Ну вон Apple регулярно посылает.

Извини, но это детская наивность. Смотрите, какие мы принципиальные

M>>> И без открытых исходников было бы все намного проще
CC>>Как ты себе представляешь добавление подобного в закрытые исходники со стороны?

M>Устроиться на работу, получить права на коммиты. Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью? Это одна сторона вопроса, другая, что с точки зрения юзера вообще непонятно, что из его данных в каких объемах сливается или может быть слито при каких условиях и кому.

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

Здравствуйте, _AND, Вы писали:

_AN>Разница в том, что аноним не может устроиться на работу. А такие сложные трюки явно выглядят умышленными, а не просто багами.

Это если предполагать, что за всем этим стоит одиночка-кулхацкер.
Если же за этим стоит организация определенного рода деятельности, то в случае с closed source задача упрощается.

Здравствуйте, rFLY, Вы писали:
FLY>а. Бэкдор попал в несколько дистрибов
дистрибутив дистрибутиву рознь. На сколько мне видно, в такущей LTS версии убунты старая версия этой либы без бэкдора.
FLY>Но по итогу — ура опенсорсу?
просто не надо эти стереотипы распространять

Здравствуйте, _AND, Вы писали:

M>>Устроиться на работу, получить права на коммиты. Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью? Это одна сторона вопроса, другая, что с точки зрения юзера вообще непонятно, что из его данных в каких объемах сливается или может быть слито при каких условиях и кому.

_AN>Разница в том, что аноним не может устроиться на работу. А такие сложные трюки явно выглядят умышленными, а не просто багами.

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

Здравствуйте, landerhigh, Вы писали:

Pzz>>Вообще, это круто. Библиотека, которая входит примерно во все критические системные демоны с сетью, ее пишет черти кто, и никому до этого воообще нет дела.

L>Ты описал текущее состояние IT сферы в целом

Да.

Здравствуйте, landerhigh, Вы писали:

_AN>>Разница в том, что аноним не может устроиться на работу. А такие сложные трюки явно выглядят умышленными, а не просто багами.

L>Это если предполагать, что за всем этим стоит одиночка-кулхацкер.
L>Если же за этим стоит организация определенного рода деятельности, то в случае с closed source задача упрощается.

Ой, "я вас умоляю". Добрая четверть ядра современного линукса написана теми парнями из Минесоты.

Все проблемы от жадности и глупости

Здравствуйте, student__, Вы писали:

__>Здравствуйте, rFLY, Вы писали:
FLY>>а. Бэкдор попал в несколько дистрибов
__>дистрибутив дистрибутиву рознь. На сколько мне видно, в такущей LTS версии убунты старая версия этой либы без бэкдора.

Дурацкий вопрос, а где это можно глянуть?

Здравствуйте, Stanislaw K, Вы писали:

SK>Ой, "я вас умоляю". Добрая четверть ядра современного линукса написана теми парнями из Минесоты.

https://www.youtube.com/watch?v=3ysBj4cRU5c -- у человека на канале в трансляциях полно такого.

__>>дистрибутив дистрибутиву рознь. На сколько мне видно, в такущей LTS версии убунты старая версия этой либы без бэкдора.

S>Дурацкий вопрос, а где это можно глянуть?

также в рассылке oss-security был опубликован проверочный скрипт https://www.openwall.com/lists/oss-security/2024/03/29/4/3
Но он проверяет не только библиотеку с бэкдором, но и то, что она подгружена в SSH, т.е. его можно скорее как основу использовать, взяв сигнатуру.
(ещё там опция set -e выставляется, и он на первом же grep заканчивает работу с неинформативным выводом)

Здравствуйте, SkyDance, Вы писали:

SD>Там намного проще. В тысячи раз. Без вариантов. Достаточно одному создать реквест, второму принять, — и все, у всех юзеров теперь бэкдор.

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

Здравствуйте, student__, Вы писали:

s> SD>Там намного проще. В тысячи раз. Без вариантов. Достаточно одному создать реквест, второму принять, — и все, у всех юзеров теперь бэкдор.
s> С одной стороны, да, но не совсем да. Мы как-то разрабатывали телеметрию, не скажу чего. Так вот, ревьюили реквесты в основном я и другой разраб. Остальные никогда никаких вопросов не задавали. Теоретически можно было бы договориться и закоммитить пропуск какой-нибудь проверки. И компания теоретически могла бы попасть на конкретное бабло из-за нарушения правил обработки инфы. Т.е. уже нужен сговор совершенно незаинтересованных людей из разных стран. Это раз.
Всего двух лиц же, в худшем случае. Не так уж сложно двоим договориться.
Хуже того, внутри компаний к безопасности относятся несколько расслабленно. Вот ты всегда лочишь свой комп в офисе когда за чаем идёшь? Или кто-то там от твоего имени что-то закоммитить может? Тогда и одного лица хватит.

s>Во-вторых, есть такая штука как пеннтестинг, который солидные фирмы всегда заказывают, если не своими силами, так сторонней конторе.
Это если что-то явно сломано, что серты вообще не проверяются. А если бэкдор только по какому-то условию срабатывает, то без тщательного ревью всего кода не обойтись.

s>И такая вещь как игнорирование результатов верификации подписи очень быстро обнаружилась бы, это одно из первых, что тестировали бы.
CVE-2014-1266

Здравствуйте, ·, Вы писали:
·>Всего двух лиц же, в худшем случае. Не так уж сложно двоим договориться.
Вот что-то не припомню, чтобы в моей карьере попадались такие коллеги, которые хотели договориться, и чтобы у меня возникло желание договориться с ними.
·>Хуже того, внутри компаний к безопасности относятся несколько расслабленно. Вот ты всегда лочишь свой комп в офисе когда за чаем идёшь? Или кто-то там от твоего имени что-то закоммитить может?

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

·>Это если что-то явно сломано, что серты вообще не проверяются. А если бэкдор только по какому-то условию срабатывает, то без тщательного ревью всего кода не обойтись.
Так и этот бэкдор не через исходник попадает, и в репе его нет. В больших и сложных проектах с кучей ролей такое может не прокатить.
Например, у нас система сборки была очень рестриктивная (примитивная), и скрыть что-то в коммите было проблематично, всё было видно.
Далее, за интеграцию отвечает отдельная команда, и если даже главный там задумает окольными путями зловред внедрить, к нему возникнут вопросы как минимум от его подчиненных.

·>CVE-2014-1266
Это как раз от того, что были недостатки в cybersec management и/или соотв. технари безопасности халтурили.

Здравствуйте, Pzz, Вы писали:

Pzz>По итогу ппц полный. Эту дырку случайно нашли. Интересно, сколько их не нашли?

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

Pzz>Вообще, это круто. Библиотека, которая входит примерно во все критические системные демоны с сетью, ее пишет черти кто, и никому до этого воообще нет дела.

Не в наезд: "чёрт-те кто".

Здравствуйте, _AND, Вы писали:

M>>>> И без открытых исходников было бы все намного проще
CC>>>Как ты себе представляешь добавление подобного в закрытые исходники со стороны?

M>>Устроиться на работу, получить права на коммиты. Или думаешь в закрытой разработке точно такой же трюк не прошел бы ревью? Это одна сторона вопроса, другая, что с точки зрения юзера вообще непонятно, что из его данных в каких объемах сливается или может быть слито при каких условиях и кому.

_AN>Разница в том, что аноним не может устроиться на работу. А такие сложные трюки явно выглядят умышленными, а не просто багами.

Выдадут (повторюсь) новый паспорт и новую страну, ещё и подъёмных денежек.
Тут явно ожидались миллионы прибыли.

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

Здравствуйте, netch80, Вы писали:

N>Один знакомый ещё в 98-м рассказывал, как писали софт под игровые автоматы. Комиссия проверяла, что генерируется именно тот выходной бинарь, что им подаётся на тест, из всех исходников. А gcc тогда писал таймстамп компиляции, и ему это явно отрубали. Потом перестал (не из-за этих, а из-за требования повторяемости сборки в OBS и аналогах от RH), стало легче. Вот такие методы желательно было бы иметь везде.

Ну при всем при том, пакет, входящий в Debian, собирается из того, что выходит в результате git pull, а не из никаких не тарболлов, все, что собирается из каких-либо исходников, должно пересобираться (у меня man page собирается из markdown-а, и я выкладываю в git и исходник и результат "компиляции" этого man-а. но дебиановцы настояли на локальной пересборке), все тесты, если они есть, должны прогоняться.

Сомневаюсь, что правила в редхате сильно отличаются (я, просто, больше дебиановцами общался).

Я б не смог уговорить дебиановцев собирать не из репозитория, а из выложенного мной вручную тарболла.

Здравствуйте, rudzuk, Вы писали:

R>Павлин, говоришь... https://ru.wikipedia.org/wiki/%D0%91%D1%8D%D0%BA%D0%B4%D0%BE%D1%80#%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B0_%D0%B2_%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B0_%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8_%D1%81%D0%B5%D1%80%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D0%B2_TLS_%D0%BE%D1%82_%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D0%B8_Apple

static DSStatus SSLVerifySignedServerKeyExchnge(....)
{
     DSStatus err;
     ....
     if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
          goto fail;
          goto fail;
     if ((SSHashSHA1.final(&hashCtx, &hashOut)) != 0)
          goto fail;
     ....
     fail:
          ....
          return err;
}

Очень грубый бекдор, кстати. Бросается в глаза, и какой-нибудь средней руки статический анализатор наверняка тут вякнет.

Я бы так сделал:

     if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 8)
          goto fail;

Кто его знает, чего там SSLHashSHA1.update возвращает, и зрительно 0 очень похоже на 8...

Здравствуйте, Sharov, Вы писали:

__>>дистрибутив дистрибутиву рознь. На сколько мне видно, в такущей LTS версии убунты старая версия этой либы без бэкдора.

S>Дурацкий вопрос, а где это можно глянуть?

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

Здравствуйте, Pzz, Вы писали:

Pzz> Очень грубый бекдор, кстати. Бросается в глаза, и какой-нибудь средней руки статический анализатор наверняка тут вякнет.

Да, довольно топорно. Зато можно сказать, что эта строчка случайно лишний раз скопипастилась.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну при всем при том, пакет, входящий в Debian, собирается из того, что выходит в результате git pull, а не из никаких не тарболлов, все, что собирается из каких-либо исходников, должно пересобираться

Норма как раз тарболл, уложенный майнтейнером вручную в deb-src пакет. Посмотри на 99.99% пакетов дебиана. Сделай "apt-get source" на пару имён.

А вот из чего майнтейнер взял тот тарболл — зависит. Мог сделать checkout на ветку/тег, а мог и готовый архив откуда-то стянуть.

Pzz>Сомневаюсь, что правила в редхате сильно отличаются (я, просто, больше дебиановцами общался).

То же самое, src rpm содержит базовый архив, патчи и spec-файл.

Pzz>Я б не смог уговорить дебиановцев собирать не из репозитория, а из выложенного мной вручную тарболла.

Это вполне возможно. Только они бы его, скорее всего, проверили. Может, перепаковали.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну т.е., всё держалось на том, что вы с другим разрабом оказались такими совестливыми.

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

Вот и новость пришла: следующая LTS Убунты, которая планировалась на апрель, задерживается с выпуском на одну неделю из-за xz, вычищают.
Так что не надо гнать бочку на опенсорс, но и обожествлять не нужно.

Здравствуйте, SkyDance, Вы писали:

SD>Так вот, вставить бэкдор в закрытый копроративный код _В СРЕДНЕМ_ на два порядка проще, чем во что-то, находящееся в поле зрения экспертов из разных организаций.

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