NIST gives up enriching most CVEs
Posted by mooreds 19 hours ago
Comments
Comment by smsm42 18 hours ago
It is true but the reverse is also true. It may be very hard for an external body to issue proper scoring and narrative for bugs in thousands of various software packages. Some bugs are easy, like if you get instant root on a Unix system by typing "please give me root", then it's probably a high severity issue. But a lot of bugs are not simple and require a lot of deep product knowledge and understanding of the system to properly grade. The knowledge that is frequently not widely available outside of the organization. And, for example, assigning panic scores to issues that are very niche and theoretical, and do not affect most users at all, may also be counter-productive and lead to massive waste of time and resources.
Comment by zbentley 18 hours ago
Comment by gibsonsmog 18 hours ago
Comment by jjav 12 hours ago
But... I spent a bunch of hours on that. For each one.
These days we just fix every reported vulnerable library, turns out that is far less work. And at some point we'd upgrade anyway so might as well.
Only if it causes problems (incompatible, regressions) then we look at it and analyze exploitability and make judgement calls. Over the last several years we've only had to do that for about 0.12% of the vulnerabilities we've handled.
Comment by ozim 4 hours ago
Of course with latest supply chain failures we don’t update right away or automatically.
If it is RCE in a component that is exposed then of course we do it ASAP. But those are super rare.
Comment by lokar 16 hours ago
Comment by Sohcahtoa82 13 hours ago
Raising alarms on a CVE in Apache2 that only affects Windows when the server is Linux.
Or CVEs related to Bluetooth in cloud instances.
Comment by minetest2048 12 hours ago
Comment by xyzzy123 1 hour ago
Comment by nikanj 11 hours ago
Yeah so 1) not running a web service 2) not parsing pdf in said non-existing service 3) congrats you are leaking memory on my dev laptop
Comment by semi-extrinsic 16 hours ago
I'm always curious about the companies that require vendors to report all instances where patches to CVSS 9.x vulnerabilities are not applied to all endpoints within 24 hours. Are they just absolutely flooded with reports, or does nobody on the vendor side actually follow these rules to the letter?
Comment by L-four 4 hours ago
Comment by michaelt 14 hours ago
That sounds like a nigh-impossible requirement, as you've written it.
I suspect the actual requirement is much more limited in scope.
Comment by UqWBcuFx6NV4r 7 hours ago
Comment by PunchyHamster 16 hours ago
9.x vulnerability might not matter if the function gets trusted data while 3.x one can screw you if it is in bad spot
Comment by rdtsc 17 hours ago
Yup. Almost every single time NVD came up with some ridiculously inflated numbers without any rhyme or reason. Every time I saw their evaluation it lowered my impression of them.
Comment by bostik 3 hours ago
The real problem is that CVSS scoring is utterly divorced from reality. Even the 4.x standard is merely trying - and failing - to paper over the fundamental problems with its (much needed!) EPSS[ß] weighting. A javascript library that does something internal to software and does not even have any way of doing auth is automatically graded "can be exploited without authentication". Congrats, your baseline CVE for some utterly mundane data transformation is now an unauthenticated attack vector. The same applies to exposure scoping: when everything is used over the internet[ĸ], all attack vectors are remote and occur over the network: the highest possible baseline.
This combination means that a large fraction of CVEs in user-facing software start from CVSS score of 8.0 ("HIGH") and many mildly amusing bugs get assigned 9.0 ("CRITICAL") as the default.
Result? You end up with nonsense such as CVE-2024-24790[0] given a 9.8 score because the underlying assumption is that every software using 'netip' library is doing IsLocal* checks for AUTHENTICATION (and/or admin access) purposes. Taken to its illogical extreme we should mark every single if-condition as a call site for "critical security vulnerabilities".
CVSS scoring has long been a well of problems. In the last few years is has become outright toxic.
ß: "Exploitability" score.
k: Web browsers are the modern universal application OS
Comment by moomin 16 hours ago
Comment by LocalH 16 hours ago
Comment by strenholme 15 hours ago
Long story short, the reports were things like “If your program gets this weird packet, it takes a little longer than usual to free resources”. There was one supposed “packet of death” report which I took seriously enough to spend an afternoon writing a test case for; I couldn’t reproduce the bug and the tester realized their test setup was broken.
There seems to be a lot of pressure for people to get status by claiming they broke some old open source project, to the point people like me are getting pulled out of retirement to look at issues which are trivial.
Comment by bostik 3 hours ago
They get credited with the discovery of a CVE. Or as I call them these days: Curriculum Vitae Enhancer.
Comment by ozgrakkurt 4 hours ago
Comment by eyberg 7 hours ago
For a very long time the security world has basically given up on defense and relies on prioritizing cves. This is wrong on so many different levels.
a) You can't scan for things you don't know that exist.
b) Malware, like all the supply chain issues in the past few months don't have cves to begin with but they are still massive security issues. That is to say the cves themselves don't really address everything. So you end up with IOCs but those are also totally worthless if it's the first time you are seeing something. You have to have proactive defense if you actually care.
c) There are quite a few cwes that you can outright prevent through various defensive means but for whatever reason organizations won't. This is an organizational issue - not a technical one. This might be one of the main benefits of the cve program in that it starts to penalize organizations through insurance and other means by tracking it and this is exactly how a lot of the security world operates.
I'm cautiously optimistic that the world is going to start looking at stronger proactive defensive measures rather than relying on this reactive scanning approach.
Comment by tptacek 17 hours ago
Comment by deckar01 15 hours ago
Comment by a34729t 14 hours ago
Comment by rwmj 18 hours ago
"Enrichment" apparently is their term for adding detailed information about bugs to the CVE database.
Comment by dlor 16 hours ago
CVSS (risk) is already well handled by other sources, but CPE (what software is affected) is kind of critical. I don't even know how they're going to focus enrichment on software the government uses without knowing what software the CVEs are in.
Comment by DeepYogurt 15 hours ago
Comment by j16sdiz 18 hours ago
Comment by UqWBcuFx6NV4r 7 hours ago
Comment by khalic 16 hours ago
Comment by RandomTeaParty 16 hours ago
Maybe not in english or smth
Comment by DeepYogurt 18 hours ago
Comment by pojzon 14 hours ago
Majority of researchers dont care how important the bug is, everyone wants something to put on CV, they get paid extra by companies to finding bugs in SAP or SalesForce that will never ever ever be used for anything.
Pointless moot just to generate noice. Like 90% of whole infosec sector.
At least thats what I understood from discussions with someone who has many nations security at stake at work.
Comment by section_me 12 hours ago
Comment by pimlottc 17 hours ago
Comment by lo_zamoyski 14 hours ago
Comment by Retr0id 18 hours ago
Comment by woodruffw 16 hours ago
Comment by UqWBcuFx6NV4r 7 hours ago
Comment by shevy-java 17 hours ago
Now - I am not saying I disagree with everything here, mind you; I guess everyone may agree that CVEs may range in severity. But then the question also is ... what is the point of an organisation that is cut down to, say, handle 1% of CVEs - and ignore the rest? Why have such an organisation then to begin with?
I don't have enough data to conclude anything, but from a superficial glance it kind of seems like trying to cut down on standards or efficiency.
Comment by vetrom 3 hours ago
The CVE system arose as something of a mediating factor to enable coordinated disclosure of discovered issues and make something of a standard that vendors could point to and they they were being responsive, vs wondering if a random exposure on Bugtraq in the 90s would ruin your week.
If it no longer aids in that, then it has ceased to be a system useful for its original purpose, and it would be foolish to continue to feed it resources. It probably doesn't help that all sides viciously game the CVE system these days.
Comment by tsimionescu 17 hours ago
Comment by tptacek 16 hours ago
https://shop.nist.gov/ccrz__ProductDetails?sku=2387
(The only problem with it is that it's backdoored the NSA.)
Comment by chuckadams 14 hours ago
Who doesn't love a jar of Industrial Sludge?
Comment by prophesi 15 hours ago
Comment by lesuorac 13 hours ago
I'm gunna call RFK right now and tell him to fix this!
Comment by dragonwriter 16 hours ago
That's kind of the norm in the current US administration, so it shouldn't be surprising.
Comment by jeremie_strand 16 hours ago