Архив метки: opensource

Мне не нравится, когда опенсурс возводят в культ и представляют как волшебное решение всех проблем, а в особенности проблем с кибербезопасностью

Мне не нравится, когда опенсурс возводят в культ и представляют как волшебное решение всех проблем, а в особенности проблем с кибербезопасностью

Мне не нравится, когда опенсурс возводят в культ и представляют как волшебное решение всех проблем, а в особенности проблем с кибербезопасностью. 😬 На самом деле опенсурс это в основном про хаос, безответственность и огромное количество неблагодарной и, как правило, неоплачиваемой работы. 🤷‍♂️

Возьмём библиотеку expr-eval из предыдущего поста. У библиотеки 800k скачиваний в неделю, она используется в куче проектов (только в npm 259 зависящих пакетов). При этом когда был последний коммит в проект? 4 года назад. 🫠 Вот исследователи нашли там критичную уязвимость, принесли фикс мейнтейнеру Matthew Crumley на GitHub, а достучаться до него не могут. Последняя активность на гитхабе в 2023 году. 🤷‍♂️ Соответственно, нет и вполне вероятно, что не будет фикса в этой библиотеке, которая остаётся доступной для использования.

Самого Matthew Crumley в этом нельзя винить, он, так-то, никому и ничего не должен. 😉 И надеюсь, что у него всё хорошо и просто человеку надоело. 🙏

Почему это нас беспокоит?

Почему это нас беспокоит?

Почему это нас беспокоит? Ситуация с финансированием MITRE и NIST исключительно внутриамериканская. И она так или иначе разрешится. В этой сфере крутятся миллиарды долларов, работают сотни компаний и многие тысячи специалистов. Они без нас найдут тех, кто будет вести и обогащать базу CVE, и кто будет это финансировать (CISA уже отсыпали MITRE денежек на 11 месяцев 😏).

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

Ответ очевиден: в России всё ещё широко используется западный коммерческий софт, уязвимости которого собираются в эти базы. Как и уязвимости западного опенсурсного софта/библиотек, составляющих основу практически всего "отечественного ПО". Из технологической зависимости растёт и зависимость от американских баз уязвимостей. 🤷‍♂️

Поэтому следует:

🔹 усиливать настоящее импортозамещение
🔹 избавляться от западных продуктов
🔹 наращивать контроль над опенсурсными проектами

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

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

Как сделать так, чтобы вендоры отвечали за уязвимости в их продуктах? Как по мне, рыночные механизмы здесь не работают. 🤷‍♂️ Работают только регуляторные и только в контексте сертифицированных решений. Только отзыв сертификата существенно влияет на бизнес вендоров. 😏

"Если б я был султан", в случае обнаружения критичной уязвимости в сертифицированной версии ПО требовал бы, чтобы

🔻 вендор объяснил, как уязвимость туда попала, с учётом реализованных процессов безопасной разработки

🔻 испытательная лаборатория объяснила, почему уязвимость не была обнаружена в ходе работ по сертификации

А дальше пусть комиссия регулятора решает, что делать и с этим вендором, и с этой лабораторией. 😈

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

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

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

А почему компании-вендоры лепят продукты из кишащего уязвимостями недоверенного опенсурса и это их ничуть не напрягает? Просто их прибыль не зависит от уязвимостей примерно никак. Для них важно, чтобы фичи для решения бизнес-задач клиентов появлялись в продукте быстро и с минимальными затратами на ФОТ. А если это можно получить сразу, бесплатно и легально за счёт опенсурсного кода - это ж просто праздник какой-то! Практически деньги из воздуха! 💰🤑 А то, что в этом софте будут находить уязвимости или даже закладки, так и что с того? Надо будет - запатчат.

Быстро поднятое упавшим не считается!

Удобное положение вещей: выпущенное обновление искупает факт наличия уязвимости. Какая бы позорная она не была! Даже если она эксплуатировалась как 0day! Было и было. 🤷‍♂️

Ставьте обновления, господа клиенты. Хоть по 10 раз на дню. 😏 И не рефлексируйте.

Пока факт наличия уязвимости в продукте стоит вендорам примерно 0, ситуация не изменится. Издержки продолжат нести клиенты. 🤷‍♂️

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше?

С чего бы количеству новых уязвимостей уменьшаться, если код не становится лучше? Даже Майкрософт с их образцовой системой выявления и исправления уязвимостей (без шуток, в этом они top-notch) и минимизацией использования чужого кода практически каждый месяц исправляет больше сотни уязвимостей в своих продуктах. Откуда-то ведь они берутся? Кто-то лепит эти баги, уходящие беспрепятственно в прод? Учитывая лаг в месяцы между тем как исследователь сообщает об уязвимости в Microsoft и, собственно, датой выхода фикса, известных незакрытых уязвимостей в бэклоге у MS должно быть очень и очень много.

Что уж говорить о компаниях попроще, продающих под видом своих продуктов сплошной суп из за… заимствованного опенсурсного кода. 🙂 Который зачастую разрабатывает полусумасшедший мейнтейнер-энтузиаст на пару с очередным фейковым Jia Tan-ом. 😈 Это они, должны требования по безопасной разработке выполнять, чтобы не допускать уязвимостей? Ну да, конечно, ждите-ждите. 😏

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux

Прочитал статью в блоге US Council on Foreign Relations (CFR) про импортозамещение в России и Astra Linux. Ссылку давать не буду. Статья довольно дурацкая и с ошибками типа вендора смартфонов "Xiamoi". 😅 Но настроения на Западе передаёт. 😉

Их основные идеи:

🔹 Русские зависят от китайских технологий. Нужно раздувать опасности, которые им это несёт, чтобы вбить клин между русскими и китайцами.
🔹 Нужно исследовать Astra Linux. Наверняка у русских ограничены возможности в области тестирования безопасности кода. США и союзники могут это использовать "to press the advantage in cyberspace".

Отсюда три вывода:

🔻 Импортозамещение - это круто, правильно и беспокоит потенциального противника. 👍
🔻 Open Source - это арена противостояния государств. Нужно вкладываться в средства контроля кода и уменьшать зависимость от сомнительных апстримов. Горячий привет российским переупаковщикам RHEL-а.
🔻 В игру с воздействием на апстримы могут играть двое. 😉 См. кейс с XZ Utils.

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсовПродолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов

Продолжаю рассказ про уязвимости БДУ без ссылок на CVE идентификаторы разбором конкретных кейсов.

🔹 Почему так много уязвимостей Astra Linux? Upd 0704. В основном это результат собственного ресёрча.
🔹 Для EMIAS OS уязвимости Linux Kernel, но даже без ссылки на бюллетень. Откуда именно уязвимость непонятно.
🔹 Откуда уязвимости Windows? Их Microsoft выпускали не как CVE-шки, а как ADVisories. Потом для них могут добавлять CVE, которые не пробрасываются в БДУ. 🤷‍♂️
🔹 Для уязвимостей Debian Linux аналогично. Они заводятся по бюллетеням DSA без ссылки на CVE на момент публикации. Затем ссылка добавляется, но в БДУ она не пробрасывается. 🤷‍♂️
🔹 Почему много уязвимостей Open Source продуктов? Потому что они заводятся по эксплойтам, в описании которых нет ссылки на CVE.
🔹 Некоторые виндоры не любят заводить CVE идентификаторы. Например, SAP часто выпускают только непубличные SAP Notes.