Bogus CVE Follow-Ups | Hacker News Reader

Bogus CVE Follow-Ups

daniel.haxx.se

This situation exposes some arbitrary and capricious aspects of the CVE process, which in turn devalues the entire system. It makes me personally less likely to take any of their assessments at face value, and I imagine others will feel the same. That is a net loss for security.

CVEs have been questionable for awhile as I have seen quite a few over the years that amount to "the attacker already has root on the machine".

The problem now, is we are entering a phase of the general IT market due to government mandates and insurers for all kinds of cybersecurity junkware. Following a CVE database and pushing scary CVEs are basically the end result and the overreaction will still be the same as many of the cybersecurity positions are no different than checklist readers since companies don't want to pay for actual engineers or skilled sysadmins.

CVEs are not what they once (ever?) where. With the proliferation of automated systems involved with vulnerability management and dependency updates, it’s possible for a single GitHub PR close event to create a CVE for an issue that verifiably, 100% does not actually exist[1].

Interesting times ahead.

1. https://tomforb.es/cve-2022-0329-and-the-problems-with-autom...

Been seeing an uptick of researchers using CVEs to get street cred. There definitely should be better governance with how things are done.

I have been in contact with the Nist a few years ago to fix some very irrelevant issues with ImageMagick CVE's which were marked as "insecure before version 7.X" in the NVD even when the fix was backported to Version 6. It made me wonder how noone from ImageMagick, nor Debian, nor anyone else gave a fuck about correcting the NVD. It just takes a single mail with a link to the backport github commit. Debian has this link almost always in their security tracker. That could probably be automated... At the same time it showed me how arbitrary the NVD (and the whole process in general) is. Some times they wanted a bit more proof, e.g. when I claimed v6 was unaffected. I had to go as far as searching the commit introducing the vulnerability to get them to believe me (which I think is good!) - this once led me to get a CVE from "unaffected" to "wontfix" on the debian tracker because of a mistake on their site.

- You don't really know what the NIST wants until you send them a mail (and even then they respond with very short messages). Apparently the same goes for MITRE... - there is no "person" behind anything - the whole process is 100% intransparent. Noone is going to see my mails ever expect for the NIST - it seems like each distro does the same work (and noone is contributing to the NVD. Though I was looking through a narrow hole with the imagemagick stuff, others are hopefully doing it)

IMO a fully transparent (but for security reasons probably partially embargoed) process could make this whole stuff much more reasonable... But I doubt either MITRE or NIST will change anything as long as there's no competition.

I had personally the "CVE Assignment Team" reject my CVE submission after a bit over a month of waiting as my request "did not include a specific product name". I provided a list of 300ish products and their specific affected firmware versions.

Reply on news.ycombinator.com