Hacker News Reader

Comment by lowbloodsugar | Hacker News Reader

TL;DR The CVE system has no authentication mechanism (to determine the authenticity of reported “bugs” or verify their reported level) resulting in a DDOS of maintainers.

A good way to make developers not care about CVEs, and therefore allow attackers to introduce real vulnerabilities, is to post lots of fake CVEs so nobody pays attention.

View on HN

The article suggests that this DDoS is incentivized by the resume-padding cachet of having a CVE to your name, a kind of Hacktoberfest-style cobra effect:

> a recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly "collecting" CVEs to enrich their resume

Naturally, such a reporter would value higher severity reports.

I haven't really thought that much about the CVE process. It's kind of strange to me that Github, Snyk, and the NVD may all have different evaluations of a report. I guess decentralization is a feature, but one not without bugs.

This doesn't seem like a fake CVE? I'm sympathetic to the maintainer, and I don't know that I would have acted any differently in his shoes, but the report correctly describes a possible scenario where the issue could defeat a SSRF check.

Agreed that it's not fake.

However, the severity score of 9.8 [1]

Whereas a remotely exploitable remote code execution bug in a windows wifi driver only scores 8.8 [2]

So the score seems very inflated to me.

[1] https://nvd.nist.gov/vuln/detail/CVE-2023-42282 [2] https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

The score is mechanically calculated from the reported properties of the vulnerability, and heavily weights the breadth of possible attack vectors. That RCE vulnerability reports that the attacker must be adjacent to the targeted system; this one would be an 8.8 as well if it had that limitation.

the CVE for the node-ip requires also few special conditions - very uncommon format (never seen IP in hex anywhere), use of `isPublic` function (this lib has more functions), and even if this two conditions were meet, there is still one more condition - the ability to do SSRF. 9.8 score in this case is crazy.

don't get me wrong, it is an issue, but not critical, making everything critical, for frontend libs on npm creates fatigue and nobody takes these scores seriously anymore. in case of real issue, nobody will care enough to patch it, as everything is critical.

I don't think you're wrong, but it gets to the underlying question of what these systems are for. If you start from the perspective that you're going to patch all known CVEs, it doesn't seem like a big practical problem that this is 9.8 - it's unlikely your system is exposed, but equally unlikely you'd have a hard time upgrading node-ip. If you're not going to patch all known CVEs, CVSS scores aren't a useful guide to which ones are absolute must-fixes; Heartbleed was famously 5.0 when disclosed, and it's still only a 7.5 on the new scale.

here's recent openssh RCE classified as 9.8 https://www.qualys.com/regresshion-cve-2024-6387/

the difference: you can find affected openssh servers, with the node-ip issue you have to find very rare instance that would allow for SSRF and create exploit for the exact use case. with openssh you can make it really broad.

so the 9.8 score for node-ip is crazy high, and nobody should question it, it should be ~6 max

Again, the score is mechanically calculated from specific features of the vulnerability, and the number of instances on the Internet which are exposed isn't one of those features.

I would agree that the CVSS is not, in this instance, measuring something particularly related to the practical importance of the vulnerability. I agree nobody can really dispute that. But does that mean that the next version of CVSS should include "I bet not many systems are exposed" or "I subjectively think this isn't that bad" dimensions? I'm skeptical - that seems like it would create more problems than it solves.

i only want the score to represent real threat, not what features it includes, as that is meaningless in the long run. i agree that it shouldn't include "i think is bad" as that is meaningless as well, the score should represent the threat, not the features.

because i'm checking dependabot [0][1] regularly, there is a lot of issues with very high scores for frontend libraries, that have really low impact, because it "checks" some features. eg some plugin for jquery (frontend lib) [2] that has the same score as heartbleed, which is insane and shows how useless the score is in current form.

- https://docs.github.com/en/code-security/dependabot/dependab...

- https://github.com/advisories?query=type%3Areviewed

- https://github.com/advisories/GHSA-ffmh-x56j-9rc3

Reply on news.ycombinator.com