Раздутый отчёт об уязвимости вынудил разработчика node-ip перевести репозиторий в архивный режим

Фёдор Индутный (Fedor Indutny), автор платформы Io.js (форк Node.js), входящий в технический комитет, управляющий разработкой Node.js, попытался привлечь внимание к проблеме с назначением CVE-идентификаторов некорректным отчётам об уязвимостях, не соответствующим действительности или неадекватно представляющим уровень опасности. Номер CVE, применяемый для идентификации уязвимости, присваивается без должной проверки и без консультации с разработчиками уязвимых программ, что приводит к появлению злоупотреблений, в которых под видом опасных уязвимостей преподносятся несущественные ошибки, на деле не представляющие угрозу безопасности.

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

В случае с Фёдором проблема коснулась Node.js-библиотеки node-ip, которая до публикации отчёта об уязвимости загружалась примерно 30 млн раз в неделю, но за 5 месяцев число загрузок снизилось до 17 млн в неделю. Предполагается, что наличие отчёта о критической уязвимости способствовало падению популярности библиотеки.

Библиотека node-ip используется в качестве зависимости у более 3500 проектов, при сборке которых из-за ложного CVE при выполнении команды «npm audit» выводится предупреждение.
Поток жалоб и сообщений, связанных с ложным CVE, привёл к тому, что после нескольких месяцев попыток добиться изменений уровня опасности в CVE разработчик node-ip перевёл репозиторий проекта в архивный режим, заморозив процесс разработки (в архивном режиме репозиторий находился 5 дней и несколько часов назад был убран).

Информация об уязвимости CVE-2023-42282 была опубликована в начале февраля, но до этого выявивший проблему исследователь с декабря 2022 года пытался добиться получения вознаграждения на платформе Huntr (вероятно уровень опасности завышают так как он влияет на вознаграждение). Судя по информации из отчёта об уязвимости, представители Huntr более года пытались связаться с разработчиками node-ip для устранения проблемы и лишь затем раскрыли детали публично.

Суть проблемы в том, что предоставляемые библиотекой функции isPublic() и isPrivate() обрабатывают только каноническое представление IP-адресов, что позволяет добиться неверного результата проверки вхождения адреса в диапазоны для внутреннего использования (10.x.x.x, 192.168.x.x., 127.x.x.x, 172.16-31.x.x) при передаче адреса в других форматах, например, 0x7f.1, и 127.1 вместо 127.0.0.1. Утверждалось, что проблема может использоваться для обхода SSRF-защиты и проверок при предоставлении доступа к ресурсам. В CVЕ проблеме был присвоен критический уровень опасности (9.8 из 10), а в отчёте на GitHub проблема была отмечена как опасная.

Автор node-ip выразил несогласие с тем, что проблема является опасной уязвимостью. В частности, для совершения атаки необходимо добиться передачи своего значения в функции isPublic() и isPrivate(), в то время как информацию об IP-адресе подключающегося клиента, как правило, получают из системных функций или переменной окружения web-сервера, которые изначально выдают только корректные значения. Ситуация, когда непроверенные данные о проверяемом IP-адресе передаются через внешние формы ввода или подконтрольные атакующему источники, выглядит умозрительной.

Из-за обилия запросов на исправление в середине февраля были сформированы корректирующие релизы node-ip 1.1.9 и 2.0.1, в которых добавлены проверки с учётом нетипичных форм представления IP-адресов. Тем не менее, с учётом популярности проекта поток связанных сообщений и запросов пользователей не прекратился. В БД MITRE уязвимость и поныне остаётся помечена как критическая, но представителей GitHub удалось убедить снизить уровень опасности в БД GitHub Advisory Database до минимального.

Из недавних отчётов с завышенным уровнем опасности также можно отметить уязвимость в LibreOffice 24.2.4 CVE-2024-5261, которой присвоен критический уровень опасности (10 из 10). Проблема,
исправленная несколько дней назад, затрагивает библиотеку LibreOfficeKit, позволяющую обращаться к возможностям LibreOffice из внешних приложений на C/C++, например, вызывать функции для преобразования форматов. Суть уязвимость в использовании по умолчанию настройки libCurl (CURLOPT_SSL_VERIFYPEER=0), отключающей проверку сертификатов при загрузке внешних ресурсов по HTTPS, например, указанных в документе внешних изображений.

Источник: opennet.ru