Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Интерпретация количества “опубликованных уязвимостей”
Попалось тут снова утверждение, что, мол, если количество уязвимостей в библиотеках с открытым исходным кодом выросло в два раза, а количество самих библиотек за тот же период – только на четверть, то это означает, что количество “угроз” растёт в четыре раза быстрее, чем “объём компонент” с открытым кодом.
Оставим за скобками способы определения “количества библиотек”, оставим за скобками и такое наблюдение, что если библиотек меньше, то их проще обновить и, тем самым, проще нивелировать угрозы. Посмотрим, так сказать, на сам принцип и на сравнение “прироста”. Тут ведь не сказано, какие именно это уязвимости. Откуда известно, что их количество выросло в библиотеках? Как вообще по количеству уязвимостей можно определять количество угроз (это сильно разные понятия и сильно разные метрики)? И так далее, и тому подобное.
Тем не менее, подобные утверждения популярны, несмотря на то, что они старые. Почему-то считается, что если больше найдено уязвимостей, то это гарантирует, что выросла и опасность ПО, в котором эти уязвимости найдены. Но уязвимости, как минимум, вносят в код раньше, чем о них публикуется информация. Понять, что отсутствует прямая связь между количеством обнаруженных уязвимостей, надёжностью ПО и количеством “угроз” – не так трудно. Я не раз писал об этом, достаточно давно.
Естественно, подобная статистика уязвимостей в ПО ведётся по обнаруженным уязвимостям, о которых опубликована информация. То, что уязвимость не обнаружена, не означает, что в коде нет уязвимостей. А обнаружение уязвимости – не гарантирует, что их в исследуемом коде много. Именно поэтому угрозы, как таковые, нельзя расставлять по обнаруженным уязвимостям. Но, конечно, в списке должны быть две-три угрозы, связанные с возможностью эксплуатации известных уязвимостей при помощи автоматических инструментов – это достаточно очевидно. Вот только количество этих угроз не растёт вместе с ростом публикаций CVE – максимум, угрозы эти можно разделить по библиотекам, то есть, максимум на четверть они вырастут, если все новые библиотеки строго тянуть в свою модель угроз (но зачем? вопрос риторический).
Во-первых, вот уже лет пять как начали присваивать статус “признанной уязвимости”, “с кодом CVE”, даже самым мелким обнаруженным дефектам, практическое значение которых при проведении атак довольно сомнительно.
Во-вторых, сейчас сам поиск уязвимостей стал настолько массовым, что, действительно, находить их стали больше, в том числе, существенных (это и капитан Очевидность подтверждает). Рост интереса исследователей – вот единственный параметр, о котором можно судить, косвенно, по количеству публикаций уязвимостей. Да, находят весьма и весьма существенные уязвимости, которым десять и более лет – внимание, вопрос: когда эти уязвимости преобразовались в угрозы, если преобразовались? В момент внесения в код, или когда об этом в газетах написали, десять лет спустя?
В-третьих, уязвимости сильно различаются по тому контексту, который их вообще делает уязвимостями и создаёт возможность установления связи с угрозами (угрозы, на минуточку, и определяются-то не по уязвимостям – см. выше). Эффект от одной и той же “уязвимости с CVE” может сильно различаться в зависимости от модели угроз (учитывается ли подключение системы к внешним вычислительным сетям; учитывается ли наличие USB-портов и возможность физического доступа, и т.д.).
Так что угрозы отдельно, поиск уязвимостей – отдельно, а наличие уязвимостей – тут вообще в другой плоскости. Наличие или отсутстие уязвимостей не мешает их поиску, – да, искать можно и то, чего в коде нет, это основной принцип “статического” анализа кода. Не мешает наличие или отсутствие уязвимостей и сортировке перечня угроз. С уверенностью можно сказать только одно: уязвимости всегда есть, даже если CVE-номер ещё не опубликовали.
P.S. Пожалуй, тут нужно привести конкретный пример. Представьте, что у вас определена следующая внутренняя угроза: “Локальный непривилегированный пользователь через уязвимость библиотеки в системном сервисе повышает права своего аккаунта и удаляет все защищаемые данные”. Зависит ли определение (хотя бы описание) этой угрозы от того, что в утилите sudo найдена уязвимость, позволяющая поднять права до суперпользователя? Нет, не зависит, хоть в определении угрозы и используется слово “уязвимость” – рассматривать такую угрозу нужно даже в том случае, если sudo вообще нет в системе. Поэтому про sudo в определении угрозы ничего нет, определение не зависит от конкретных уязвимостей, так как они рассматриваются в самом общем смысле. Появилась ли эта угроза лишь после того, как опубликовали данные об уязвимости в sudo и демонстратор (PoC)? Нет, конечно – угроза была и раньше. Появление информации о новой уязвимости (плюс один к количеству индексов в базе сканера), тут никак не повлияло на количество угроз.
Адрес записки: https://dxdt.ru/2025/07/17/15954/
Похожие записки:
- KDE и "крахи"
- ML-KEM и возможности бэкдоров без гибридов
- Ранжирование Apple приложений-мессенджеров
- Вычисления на одном кубите
- Исчезновение "фрагментации Интернета" с разных точек зрения
- Техническое: приложения, аутентификация и отпечатки ключей
- ИИ и формулы окружностей
- Централизованные мессенджеры и многообразие мест хранения сообщений
- Контринтуитивное восприятие ИИ на примере из криптографии
- Отключение "подключенных" автомобилей
- HTTPS-запись в DNS для dxdt.ru
Кратко этот сайт характеризуется так: здесь можно узнать про технологический прогресс, Интернет, математику, криптографию, авиацию, компьютеры, авиационные компьютеры, вооружения, роботов, вооружение роботов, армии мира, астрономию, космические исследования. И иногда о чём-то ещё (
Написать комментарий