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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+100%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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, вычищают.
Так что не надо гнать бочку на опенсорс, но и обожествлять не нужно.

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

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

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