MITRE подтвердило: curl не выдал CVE для «уязвимости» с точкой в начале имени хоста
A CVE Dispute
Автор curl, Даниэль Стенберг, рассказывает о первом споре по CVE с момента получения статуса CNA. Проект отказался присваивать CVE проблеме, связанной с некорректной проверкой wildcard-сертификата для имен с ведущей точкой, посчитав ее слишком маловероятной для эксплуатации. MITRE трижды запрашивало обоснование и в итоге согласилось с решением curl, не признав проблему уязвимостью. Стенберг подчеркивает, что выдача CVE влечет огромные издержки для экосистемы, поэтому важно избегать ложных тревог.
Каждый CVE несет огромные издержки, которые ложатся не на нас, а на экосистему, и мы не должны их игнорировать.
- ealready_value
> Каждый CVE несёт в себе огромную цену. Цену, которая ложится не на нас, и мы её не видим и не чувствуем, но это цена для экосистемы, которую, я считаю, мы не должны игнорировать.
Я очень ценю такое отношение, потому что оно признаёт, что существует множество команд безопасности, которые не смотрят на CVE нюансированно. Например, однажды у нас была команда безопасности, которая потребовала пропатчить пакет поддержки VMware, установленный по умолчанию в Ubuntu, но CVE требовал запуска на VMware, в то время как мы работали на EC2. Спорить с ними было бессмысленно, потому что они не были заинтересованы в определении, применим ли этот CVE к нам, им нужно было только, чтобы его исправили.
Многие команды, которые должны отвечать за безопасность, не задают вопрос "влияет ли этот CVE на нас", а просто перекладывают бремя патчинга вниз и наружу. В некоторых случаях, как с легко обновляемыми и централизованно развертываемыми SaaS-продуктами, это бремя скорее раздражает, чем трудно. В других случаях, например, когда у вас сложное развертывание или обновления контролируются клиентами, эти требования создают огромную нагрузку на команды, которые не принимали решения патчить каждый незначительный CVE.
- Aurornis
Было бы показательно увидеть некоторые из электронных писем, которые этот человек отправлял в MITRE, пытаясь бороться с этой проблемой.
Мы все знакомы с тем, как некоторые используют LLM для написания кода и отправки PR, но растёт проблема людей, использующих LLM для неустанной борьбы с проблемами с помощью писем и даже предложений физической бумажной работы.
Теперь, когда усилие, необходимое для спора с учреждением, стремится к нулю, всё больше людей приходит к идее использовать свою LLM и автоматизацию для борьбы в некоторых битвах. Кажется, что это стоит им очень мало, но если есть ненулевой шанс личной выгоды, они это делают. Я слышу много историй о том, как местные правительства и административные офисы университетов перегружены запросами, которые продолжают поступать от неутомимых отправителей, считающих, что попросить что-то стоит попробовать, даже если нет шансов, что это будет предоставлено.
Думаю, нам придётся пересмотреть многие наши системы коммуникации и запросов, которые ранее полагались на тот факт, что большинство людей не будут прилагать усилия, чтобы спорить о том, чего они не заслуживают. Когда стоимость спора стремится к нулю, машина может продолжать пытаться получить ненулевой шанс успеха для них.
- rwmj
Стимулы сейчас действительно плохие. Традиционно имя на CVE против важного проекта, такого как curl, имело определённый престиж в сообществе. Можно даже использовать это для повышения зарплаты или получения лучшей работы, так что деньги определённо были частью этого.
Теперь многие люди бросают код в LLM, а затем копируют и вставляют то, что получается, в "отчёты о безопасности".
Мы решили для наших проектов, что любые сгенерированные LLM отчёты о безопасности просто копируются в публичный список. У всех есть доступ к LLM, так что если один экземпляр LLM нашёл это, то все пользователи LLM уже нашли или скоро найдут. Мы исправим их, если они важны, но соотношение сигнала к шуму довольно плохое.
Я думаю, что в конечном итоге это приведёт к более безопасным сервисам, поскольку низко висящие проблемы будут найдены и исправлены. Но, к сожалению, я не вижу, чтобы поток бессмыслицы, генерируемой LLM, закончился в ближайшее время.
- woodruffw
Такой адский опыт — отличный пример того, как система CVE пытается усидеть на двух стульях: когда она в нападении, это богатый источник информации для защитников, а когда в защите — это просто непрозрачный идентификатор для координации, который ничего не говорит о качестве или правильности лежащего в основе отчёта.
- cynicalsecurity
Кто-то, видимо, очень хотел добавить это в своё резюме.