> This opens the door for a lot of infosec drama. Some of the organizations that issue CVE numbers are also the makers of the "reported" software, and these companies are extremely likely to issue low severity scores and downplay their own bugs.
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.
zbentley 17 hours ago [-]
Very true. So many regulated/government security contexts use “critical” or “high” sev ratings as synonymous for “you can’t declare this unexploitable in context or write up a preexisting-mitigations blurb, you must take action and make the scanner stop detecting this”, which leads to really stupid prioritization and silliness.
gibsonsmog 17 hours ago [-]
At a previous job, we had to refactor our entire front end build system from Rollup(I believe it was) to a custom Webpack build because of this attitude. Our FE process was completely disconnected from the code on the site, existing entirely in our Azure pipeline and developer machines. The actual theoretically exploitable aspects were in third party APIs and our dotNet ecosystems which we obviously fixed. I wrote like 3 different documents and presented multiple times to their security team on how this wasn't necessary and we didn't want to take their money needlessly. $20000 or so later (with a year of support for the system baked in) we shut up Dependabot. Money well spent!
jjav 11 hours ago [-]
Very early in my career I'd take these vulnerability reports as a personal challenge and spent my day/evening proving it isn't actually exploitable in our environment. And I was often totally correct, it wasn't.
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.
ozim 3 hours ago [-]
That’s basically my experience as well. Just upgrading is much easier and cheaper.
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.
lokar 16 hours ago [-]
My favorite: a Linux kernel pcmcia bug. On EC2 VMs.
bostik 47 minutes ago [-]
I'll top that: wireless-regdb out of date. Against an EC2-specific kernel.
xyzzy123 33 minutes ago [-]
Kernel headers out of date -> kernel vulnerability... in a container.
bostik 24 minutes ago [-]
Okay. You win.
Sohcahtoa82 12 hours ago [-]
In a similar vein:
Raising alarms on a CVE in Apache2 that only affects Windows when the server is Linux.
Or CVEs related to Bluetooth in cloud instances.
minetest2048 11 hours ago [-]
Or raising alarm on a CVE in linux mlx5 driver on an embedded device that doesn't have a pcie interface
xyzzy123 30 minutes ago [-]
ReDoS at CVSS 8+ ... in the configuration file parsing of a bundler.
nikanj 10 hours ago [-]
”If you use that installed Python version to start a web server and use it to parse pdf, you may encounter a potential memory leak”
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
semi-extrinsic 15 hours ago [-]
Every month when there is a new Chrome release, there is a handful of CVSS 9.x vulnerabilities fixed.
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?
L-four 3 hours ago [-]
The classic we need a 3 month approval process to update software but at the same time use SaaS that updates daily and breaks every other week.
michaelt 13 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.
That sounds like a nigh-impossible requirement, as you've written it.
I suspect the actual requirement is much more limited in scope.
UqWBcuFx6NV4r 6 hours ago [-]
No. It’s extremely common for security standards to be completely out of step with what’s actually viable in an organisation, and for aspects of them to be ignored, unspoken.
PunchyHamster 15 hours ago [-]
the rating is nonsense anyway, which one actually applies to code you run varies wildly
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
rdtsc 16 hours ago [-]
> It is true but the reverse is also true.
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.
bostik 2 hours ago [-]
Problem is not just NVD issuing inflated scores. That's their workaday MO. They are required to assume the worst possible combination of factors.
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
Pretty sure if I had to bet on incentives or expertise, I'd bet on incentives every time.
LocalH 15 hours ago [-]
Also, sometimes CVEs aren't really significant security issues. See: curl
strenholme 14 hours ago [-]
The deluge of new security reports is somewhat of a pain in the butt for those of us who have written notable open source software decades ago that is still in use. I recently got about a dozen reports from one reporter, and they look to be AI-assisted reports.
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.
bostik 2 hours ago [-]
> get status by claiming they broke some old open source project
They get credited with the discovery of a CVE. Or as I call them these days: Curriculum Vitae Enhancer.
ozgrakkurt 3 hours ago [-]
What do you think about new hype around anthropic breaking open source security?
eyberg 6 hours ago [-]
So first off - NVD has been sliding for a long time now. This has nothing to do with mythos. The amount of money that goes into this program for the output is straight up criminal.
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.
tptacek 16 hours ago [-]
The NVD was an absolutely wretched source of severity data for vulnerabilities and there is no meaningful impact to vendors/submitters supplying their own CVSS scores, other than that it continues the farce of CVSS in a reduced form, which is a missed opportunity.
deckar01 14 hours ago [-]
Mitre used to issue CVEs within 24 hours. I am going on 4 months now with no follow up, and no way to tell them GitHub issued a CVE already… I’m pretty sure they were just rubber stamping before. Considering disclosure normally should be coordinated with maintainers, 3rd parties like Mitre don’t seem to have much to offer or much to gain other than being a bottleneck.
a34729t 13 hours ago [-]
Honestly im surprised private industry doesnt take this over. Everybody already has their enriched, supplemental data on top of the Mitre/NVD definitions.
"Enrichment" apparently is their term for adding detailed information about bugs to the CVE database.
dlor 15 hours ago [-]
Enriching does a few things, but the main ones are adding CVSS information and CPE information.
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.
DeepYogurt 14 hours ago [-]
CPE is a joke. The offical spec doc asserts that correctness of names is not in scope for the spec. See section 5. Well-Formed CPE Name Data Model
TBH, I don't see much enrichment they are giving in last 5 or 6 years.
UqWBcuFx6NV4r 6 hours ago [-]
“Security researcher culture” is irreparably broken. It wasn’t an always like this, but it was certainly well in motion long before LLMs hit the scene. Widespread dishonesty and prestige-at-any-cost behaviour that has made everything worse as a result. So many people doing the equivalent of dumping their waste in the ocean. Heartbleed was the obvious turning point, and that’s far from an original take.
khalic 15 hours ago [-]
I can’t help but draw a connection with the numerous budget cuts from this admin, including the almost-crisis from last year with NIST.
RandomTeaParty 15 hours ago [-]
I was always wondering - are there alternative lists like this?
Maybe not in english or smth
DeepYogurt 17 hours ago [-]
Long overdue to be honest.
pojzon 13 hours ago [-]
Im close to Security MVP for EU parliment, listening on weekend bbq how stupid and pointless vast majority of CVEs are and how stupid and pointless majority of reports are - thank god someone wants to put an end to this.
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.
section_me 11 hours ago [-]
[dead]
pimlottc 16 hours ago [-]
What is the data that NIST is adding for enriched entries?
lo_zamoyski 13 hours ago [-]
I can't parse this grammatically-tortured title.
Retr0id 17 hours ago [-]
Maybe we should just assign UUIDs
woodruffw 15 hours ago [-]
Separate from everything else, this would have the virtuous effect of reducing clout-chasing via CVE IDs. It's not quite as cool (for some definition of "cool") to have 095503C9-B080-4C43-AAB6-B704DEB2FAF7 on your resume as it is to have CVE-20XX-YYYYY.
UqWBcuFx6NV4r 6 hours ago [-]
Yep. Let’s make them long and boring. Too long to comfortably fit into a CV, personal site ‘about’ section, or twitter bio.
shevy-java 16 hours ago [-]
> Going forward, NIST says its staff will only add data—in a process called enrichment—only for important vulnerabilities.
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.
vetrom 2 hours ago [-]
I think you have to look at the history of disclosure from the 90s to get a good grip here --
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.
tsimionescu 16 hours ago [-]
NIST does many other things in addition to handling the CVE database.
tptacek 16 hours ago [-]
Like producing the world's most premium peanut butter!
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.
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.
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.
Raising alarms on a CVE in Apache2 that only affects Windows when the server is Linux.
Or CVEs related to Bluetooth in cloud instances.
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
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?
That sounds like a nigh-impossible requirement, as you've written it.
I suspect the actual requirement is much more limited in scope.
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
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.
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
0: https://osv.dev/vulnerability/CVE-2024-24790
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.
They get credited with the discovery of a CVE. Or as I call them these days: Curriculum Vitae Enhancer.
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.
"Enrichment" apparently is their term for adding detailed information about bugs to the CVE database.
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.
https://csrc.nist.gov/pubs/ir/7695/final
Maybe not in english or smth
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.
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.
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.
https://shop.nist.gov/ccrz__ProductDetails?sku=2387
(The only problem with it is that it's backdoored the NSA.)
Who doesn't love a jar of Industrial Sludge?
[0] https://www.youtube.com/watch?v=esQyYGezS7c
I'm gunna call RFK right now and tell him to fix this!
That's kind of the norm in the current US administration, so it shouldn't be surprising.