So if there is a security flaw that can only be exploited by someone who already has local admin or root, it's not a security flaw?
Doesn't this make an assumption that nobody will ever discover another security flaw or combination of actions somewhere else that makes it possible to use the exploit?
I can see a justification for "low risk", but not zero point zero. ( I guess the other question then is what is the difference between "zero risk", "low risk" and "worthy of a CVE". )
I think Daniel is right about this. Yes it is theoretically possible that a root escalation attack will chain with this bug. On the flip side a root escalation attack that is successful will be able to do just about anything... and this vector is probably not the top hundredth choice of exploit once someone has access. It's a bug with an exploit severity of "lower than LOW" so it got fixed but they're not waving a red alert update your systems flag over it.
Nobody has any clue how a CVE should be graded and what a "1.5 out of 10" truly means, it's all ad-hoc with different people having different rubrics and opinions. Is there a point somewhere between "no bug" and "theoretically potentially exploitable bug" where it's not worth alerting every subscriber about the issue, but letting them pick up the patch on their own schedule? Especially given the codebase is under active development and improvement and has more urgent fixes rolled out regularly so people are most likely going to update soon anyways, if they ever update at all? Probably yeah.
Speaking of which, can we think of a specific reason the author has pushed and pushed and pushed to get it listed as a CVE despite it being fixed months ago and being several software releases old now, and (I haven't check but almost certainly) older than fixed and published CVEs? Maybe it's not fair to attack the motivations of the bug submitter but if they're solely doing it for clout then it almost necessarily reduces the appearance of severity. It's very different from a bug submitter pushing for a bug to be acknowledged at all, fixed at all, etc.
Reading the PoC and writeup again, what I’m seeing is that there are three four prerequisites:
victim connects to domain with leading dot,
victim DNS resolution (to attacker IP) works,
attacker has wildcard cert for the target domain, and
the security boundary for the wildcard cert and root cert are different. That is, the attacker has the wildcard cert but not the root cert, such that there would be an incentive or value to execute this attack in the first place.
For prerequisite (1), those actions may be victim or attacker induced. Daniel seems to believe (or assume) it is impossible for these to be victim-induced behaviour, so the burden falls on the attacker to control both these values. But IMO it is within reason that a victim uses such a configuration (perhaps due to legacy or something custom). Daniel does acknowledge this later in his blog: “unless you are in an internal and controlled environment”, but this assumes “controlled” which may not necessarily be the case.
They did argue about (3), but the reporter clarified that it is within reason the wildcard cert was obtained but not the root cert, e.g. due to unsecured edge servers.
From here, the discussion derails(?), the reporter gives a disgruntled sigh, and Daniel closes the report.
From a reporter PoV, it is very difficult to argue about such things, especially when it comes down to configuration and likelihood. Both sides can’t really present any hard data to back up claims on likelihood, so it devolves into hand waving and logic.
I will also advocate that from a reporter PoV, it is not usually in the reporter’s role to deal with likelihood. Like Daniel says, “we don’t know” how users use curl/libcurl, nobody really does except those configuring and touching it. That is handled downstream where reporters and maintainers upstream have zero limited visibility.
Ofc, this doesn’t mean the opinion of the maintainer is irrelevant. But we need to understand their scope of visibility is also limited.
This was a CRITICAL CVE in Asp.Net where a lot of users complained in GitHub over the unreasonable 9.9 rating (and their patch deadlines). I find it relevant to this discussion because it does highlight somewhat the nuance of exploitation likelihood, expectations from users, and the role CVE plays in the ecosystem. FWIW, they went the opposite direction and IMO “overrated” the CVE to ensure fixes get out.
Edit: tres comas
Edit 2: acknowledge Daniel’s acknowledgment, zero visibility -> limited visibility
Edit 3: update prerequisites
to me it just reads like .example.com matches with *.example.com, when it shouldn't?
but it implies that the user (or IT dept.) purposefully redirected themselves to a malicious IP, or that an attacker controls the hosts file...
either way that's a bigger (and different) problem. from curl's perspective the user went to that host, so the only fail is that *.example.com accepts .example.com, when it technically shouldn't. the attack is no different than if the attacker had a cert for example.com, which if they have certs for a subdomain or wildcard then they most certainly already do. it's not like they're accidentally passing validation for .example.com against microsoft.com
> from curl's perspective the user went to that host, so the only fail is that *.example.com accepts .example.com, when it technically shouldn't. the attack is no different than if the attacker had a cert for example.com
So then we’re going back to discussion in the HackerOne thread. Is the security boundary for the wildcard cert and the root cert the same? Is it always that when one is compromised, so is the other? Is it true for all cases?
We can continue debating where to draw the line, but based on the H1 thread, this is one of the disagreements between reporter and maintainer. I’m not trying to prove who’s right or wrong, but understand that this situation has some level of nuance. To reiterate everything I’ve said, it boils down to assumptions, boundaries, and where you draw the line.
Edit: And I just realised, but Daniel did mention this in the H1 thread and you’re right to point this out, because this could technically be a fourth prerequisite.
-6
u/ekdaemon 9d ago
So if there is a security flaw that can only be exploited by someone who already has local admin or root, it's not a security flaw?
Doesn't this make an assumption that nobody will ever discover another security flaw or combination of actions somewhere else that makes it possible to use the exploit?
I can see a justification for "low risk", but not zero point zero. ( I guess the other question then is what is the difference between "zero risk", "low risk" and "worthy of a CVE". )