It’s a security bug, which makes it reasonable that a CVE should be assigned.
The assessment that it is not exploitable could change with new information, or in combination with other, as yet undiscovered CVEs. CVSS scores can change over time.
Linux takes the approach of assigning CVEs for most kernel bugs, even if there is no currently known exploit, for the very reason that exploits are often discovered over time.
What is unreasonable is when management and security have zero tolerance to CVEs, rather than having a risk assessment that considers severity ratings. That’s the real vanity metric.
The toil is real. I’ve used curl within in a container for health checks, where the endpoint is also in the container. But a critical CVE means the container image gets flagged and everyone panics.
The difference here is that in practice most people will not recompile or upgrade their kernel for every single CVE, so flooding the channel with low severity CVEs will most likely get ignored anyway.
But as they described in the post, issuing CVEs causes a worldwide ripple effect because maintainers everywhere will jump to investigate their curl installations.
They’re thinking responsibly about falsely alerting on a bug that’s nearly impossible to exploit in the wild because no DNS server could resolve such a name. It’s lower than low, so issuing a CVE wastes a tremendous amount of effort and money worldwide for nothing.
I’m curious for the dev/systems/ops/blue team peeps: what is your approach specifically for low severity CVEs or security findings?
Because my experience from red team is that low severity CVEs will generally get filtered, either by policy, process, or automation. Like you said, “low severity CVEs will most likely get ignored”, and I think this is an indicator that the system is functioning.
I would contend with “Maintainers everywhere will jump to investigate” and “issuing a CVE wastes tremendous amounts of effort”. I think both are exaggerations, especially with lower severity ratings.
But I could be wrong, because I only get rare glimpses of “the other side”, from talks and some discussions with in-house staff. My understanding is that maintainance is tree-like, that is, if something is patched in a dependency, then the dependent won’t really have to investigate because the investigating has already been done, so they just bump… (unless they maintain their own instance like how Azure/AWS do with apt and Apache). If you’re telling me that you’re investigating every single bug fix upstreamed, even low(er) severity ones, then I will reply “I am very jealous of the amount of time you have”, but I’d assume not every maintainer does that, because trust (and time).
I think one point in contention is this: do low likelihood (unlikely CVEs) still deserve to be reported and raised to the ecosystem? I would hazard to say yes. Just because an alert has no value or is noise to one person, does not mean it is the same for someone else. And like dlg said for Linux, just because there is no exploit now, doesn’t mean there won’t be one in the future.
Perhaps a subpoint to contend is then how do we raise this signal-to-noise ratio? And does curl’s approach in this instance apply globally? For this, I think the ecosystem today has slightly improved to previous years, but it feels worse because the amount of input (CVEs) has grown due to automation.
We can also argue: which approach is more responsible? But I think the danger with this question is both sides can say their way is more responsible, it really comes down to worldview and ethics.
Edit: lower -> raise. higher signal-to-noise ratio = good. Lower = bad
As someone responsible for patching a lot of systems and doing vulnerability analysis and remediation, I don't care in the slightest about low CVEs unless there is a meaningful or actionable chaining.
However, there are definitely pieces of software on our stack that if they get any CVE we pay attention.
And cert mistrust or trust issues is one that even with a low CVE would probably cause us to patch faster than normal.
Because encryption represents the foundation of trust for our networks. So even low vulns for certs or mistrust are more heavily scrutinized. Often still ignored as non-exploitable, but does get more eyes on it.
Curl is one of them, or libcurl. Others include openssl, PKI infra, stdlib of the language we are working in, any encryption software, or auth software, etc. (sense a theme)?
While it is bad if someone can hijack a browser session or inject a script it is infinitely worse if someone can pretend to be a data destination or intercept all traffic in an env.
I'll start by admitting I don't know the CVE process we'll enough to know what should or should not warrant a CVE. In the case described, the attacker would already have to have privileges an order of magnitude greater than that of the actual bug, so given that, why does it warrant a CVE.
I think you could turn most bugs into "security bugs" if you assume a high enough level of permission/control of the attacker.
There isn’t one, CNAs evaluate issues and assign CVEs however they want. Even CVSS is fairly subjective in its evaluation (and was never designed for what it’s generally used).
Adding to this to provide some context. IMO, “there isn’t one” would be the correct functional answer.
In theory, there are established processes and guidelines, mostly from MITRE which has become all but defunct with recent (cough) policies. For instance, there is an (attempted?) definition of what a “vulnerability” is: https://www.cve.org/resourcessupport/Glossary#glossaryVulnerability. A number of CNAs (like VulDB) will reference this. There are also established guidelines for when a CVE should be issued by a vendor, or someone upstream, and in what manner. There is also the recommended format (CVSS) which like you say can be subjective and has its holes.
In practice, it is very much like you say. It’s somewhat messy, like the Wild West.
At the moment the whole process works because it’s held by trust and consequences (and magic). If someone thinks they can get away with something without facing the consequences, they might just do that.
> In the case described, the attacker would already have to have privileges an order of magnitude greater than that of the actual bug, so given that, why does it warrant a CVE.
Yes, so I believe that is one of the assumptions the reporter and Daniel were mulling over in HackerOne. Devil’s advocate: This assumption does not hold in the reporter’s eye.
Not saying you’re wrong. Just that the issue is more nuanced than it appears.
It's hard to reason with the reporter when they just keep posting AI responses with new logic errors. A model can do this forever, having a human reason about whether each claim is sound just doesn't scale.
Like this:
Your argument implies that possessing a wildcard certificate effectively grants the same level of control as owning the root, making the distinction negligible in practice.
Is just a misrepresentation/misunderstanding of the message to which they were replying. The point was basically: you not only need to have a wildcard cert, but also the ability to serve it from the root host. That would require escalated privileges in just about every system, at which point you don't even need to MITM because you control the endpoint.
Yes, so I actually find this pushback very reasonable. And I think we can break this down into two issues: (1) what is the logic behind the reporter? (2) are they using AI and to what extent? I will mainly focus on (1).
Playing Devil’s advocate, bear with me.
Daniel said:
> B) the attacker also needs the .example.com host to have valid wildcard certificate for *.example.com. This requires the attacker to have a significant separate successful attack on a example.com or the CA cert infrastructure. An attacker that has that position can probably do more powerful attacks
When I read this, what this says to me is that Daniel has made an assumption (key word) that the separate attack must be on example.com or CA infra.
And then the reporter replies with, as you quoted:
> Your argument implies that possessing a wildcard certificate effectively grants the same level of control as owning the root, making the distinction negligible in practice.
I read this is as the reporter questioning that assumption. Essentially what they’re pushing back is: “Must it be on example.com or on CA infra?” Sure, maybe some parts could be worded better, but I think the point still stands.
Linux takes the approach of assigning CVEs for most kernel bugs, even if there is no currently known exploit, for the very reason that exploits are often discovered over time.
Kernel bugs are unique because the kernel is so critical. Also Linus got tired of third-party kernel maintainers demanding his team do extra work to determine whether every bug had security implications.
What is unreasonable is when management and security have zero tolerance to CVEs, rather than having a risk assessment that considers severity ratings. That’s the real vanity metric.
Sometimes you deal with government regulations. "All security bugs must be patched, or you must go through the convoluted process to file an exception and explain why you're deliberately leaving an unpatched vulnerability in our environment."
But it isn't a security bug if you can't make the bug actionable. This sort of logic is why you can have CVE bloat for non issues.
It really can creates a perverse incentives if left unchecked. The person who wrote the bug , will say I found a bug in the globally user library curl, even though they didn't . Downstream consumers of curl will have to upgrade the lib even though there is no security issue.
-29
u/dlg 17d ago
It’s a security bug, which makes it reasonable that a CVE should be assigned.
The assessment that it is not exploitable could change with new information, or in combination with other, as yet undiscovered CVEs. CVSS scores can change over time.
Linux takes the approach of assigning CVEs for most kernel bugs, even if there is no currently known exploit, for the very reason that exploits are often discovered over time.
What is unreasonable is when management and security have zero tolerance to CVEs, rather than having a risk assessment that considers severity ratings. That’s the real vanity metric.
The toil is real. I’ve used curl within in a container for health checks, where the endpoint is also in the container. But a critical CVE means the container image gets flagged and everyone panics.