Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Open Source и добавление “вредоносного кода”
Часто попадаются в публикациях СМИ утверждения, что, якобы, это особенность “open source” в том, что в такие библиотеки и другое ПО включают “вредоносные возможности”. Но это не так. Модель распространения ПО никак не связана с возможностью добавления “вредоносного кода”: добавить такой код можно и в исходники, и в скомпилированный исполняемый код, а добавить что-то такое в скомпилированный код даже может быть проще, поскольку исходники ещё собирать кто-то будет и “зловредная нагрузка” может не собраться, собраться не так или не попасть в исполняемый код.
В подобных сообщениях СМИ, конечно, перепутаны подходы и термины. Открытый исходный код (Open Source) – это открытый исходный код. ПО, поставляемое с открытым исходным кодом, может быть проприетарным и коммерческим. Проблемы, о которых изначально шла речь, связаны с моделями и способами разработки кода, под открытостью тут подразумевается даже не свободная лицензия, а то, что, потенциально, любой желающий может предложить доработки и изменения. Но не факт, что предложенное будет принято безо всякой проверки. При этом в разных проектах устроены различные процессы проверки, той или иной степени защиты.
Естественно, трудности вызывает современное разделение по библиотекам и направлениям, которое приводит к тому, что возникает “развесистая” система зависимостей, за которой очень сложно, – даже невозможно, – уследить. Хрестоматийным примером тут является “экосистема” Node.js, где едва ли не под каждую элементарную подпрограмму делается отдельный “модуль”, а количество “вложенных зависимостей” очень велико. Но, естественно, речь не только про Node.js. Источники могут использовать самые разные правила добавления кода, а бывает так, что одиночная небольшая библиотека встроена в тысячи продуктов, которые тянут её код с собой. И вот, предположим, исходный репозиторий этот библиотеки оказался заброшен, а потом был взломан. Взломавший теперь получает возможность потенциальной инъекции произвольного кода в те самые тысячи продуктов. Но такая инъекция всё же может быть обнаружена.
Самое интересное, что сейчас во многих и многих программных продуктах, распространяемых в “бинарном исполняемом коде”, даже с закрытыми (условно) исходниками, всё равно присутствуют различные библиотеки из Open Source. Это касается и операционных систем, да даже и Windows. Про то, как можно рассматривать открытые исходники и “бинарный код” с точки зрения ИБ – я недавно публиковал отдельную записку. Но главное, не нужно смешивать “открытые исходники” (Open Source) с проблемами неконтролируемого добавления кода в некоторых способах коллективной разработки, равно как и с самой возможностью добавления “вредоносного кода” – такой код добавить можно и в виде “бинарной” вставки (то есть, фрагмента машинного кода).
Адрес записки: https://dxdt.ru/2023/06/23/10377/
Похожие записки:
- "Интеллект" LLM в повторах
- Техническое: экзотические настройки в SPF
- Централизованные мессенджеры и многообразие мест хранения сообщений
- Реплика: ЕГЭ от YandexGPT
- Kyber768 и длина сообщений TLS
- Кибератаки, самоуправляемые автомобили и бот в смартфоне
- Реплика: компиляторы С, "написанные" LLM
- Удаление "неактивных" google-аккаунтов
- Таблицы подстановок: картинка
- Реплика: гарантированные "маловероятные ошибки" в ML-KEM
- Разбор ситуации с неавторизованными сертификатами для 1.1.1.1 от Cloudflare
Кратко этот сайт характеризуется так: здесь можно узнать про технологический прогресс, Интернет, математику, криптографию, авиацию, компьютеры, авиационные компьютеры, вооружения, роботов, вооружение роботов, армии мира, астрономию, космические исследования. И иногда о чём-то ещё (
Написать комментарий