Hacker News Reader

Comment by paddlepop | Hacker News Reader

MITREs response to this is a perfect example of the old-school security team mindset. If I had a nickel for every security team I've worked with that a) treat reporting as gospel and don't validate it, and b) don't talk to the developer. From my experience the key issue is they don't understand the issue enough to engage in a meaningful discussion with the developer

View on HN

But the biggest issue is that they refuse that we become the CNA for VLC bugs.

So, they are the root CNA for VLC bugs, and they don't triage them correctly. And don't update the issues when we mention them.

Why can't you be an authority of your CVEs without consulting an American gov agency? I'm sure, VLC org is way more trustworthy for nine out of ten people on the Earth.

Because everyone uses CVE. And then, it gets in the press...

Not allowing CNA seems to be the biggest issue. Long time ago we had issues where getting a new cve for an open source project was really rare and hard to achieve. Now anyone who asks gets one without validation. Two extremes, likely due to lack of resources, but they won't share the load...

I think that this CVE issuance problem is getting worse recently where as in prior years there was just a smaller volume of CVE's being assigned. This VLC issue is the kind of CVE that could have been resolved by looking into it (or better assigned/described), and instead turned into a problem. There are also a string of people using security fuzzers to find issues but instead of them being triaged with security in mind they are getting CVE's issued. Some of the CVE's after investigation are test/utilities, pieces of code that are uncommon to be distributed, and a couple times code that is never called at all and was a function that never got cleaned up but when isolated had a stack overflow.

As someone who was recently a security engineer the treating as gospel is a real problem. In reviews of new CVE's you always ended up having to do the legwork to see if it was even relevant. Older CVE's I felt like usually were at least tied to something mostly concrete but the number of times I find the security report and it's just basically a valgrind/fuzzy lop output I am frustrated in the quality of reporting.

The other half of it is the journalists chasing clicks and researchers who name vulns to increase their status. That practice has really been a lot of crying wolf and it's starting to show. We had to create a special categories for vulnerabilities that were named/publicly visible and may or may not even be relevant to us just to respond to inquiries (especially things that were named but mediums on a NIST 90 day timeline but people expected resolved day 0-1).

> treat reporting as gospel and don't validate

Indeed, and they've been doing the same thing with projects like jackson-databind. 10s of completely meaningless CVEs issued for each new deserialization gadget that someone finds and gets added to a blacklist designed to protect a known-unsafe use-case (deserializing user input whilst defaultTyping is enabled).

It causes a huge waste of resources on the blue side.

Reply on news.ycombinator.com