curl: a CVE dispute
59 points by eugeny
59 points by eugeny
libcurl is installed in somewhere around thirty billion instances on the globe. If we imagine that at least a sizeable portion of those installs are managed by people who want to make sure they use a secure version, it means that every CVE we publish trigger activities in many security teams all over the world, leading to a significant number of patches and subsequent software updates.
Every CVE thus has this huge cost tied to it. A cost that does not land on us and we don’t really see or feel it, but a cost on the ecosystem I believe we should not ignore. We should act responsibly. Never ignore real problems of course, but also to make sure we don’t ring the alarm for theoretical problems that will not trigger any vulnerability.
This is refreshing and seems like the polar opposite of the Linux kernel's approach to CVEs.
Curl has enough security people per issue. Linux would need a few full time people just identifying the scope all day long. There's no practical approach for them to mirror what curl does.
Reminds me of https://devblogs.microsoft.com/oldnewthing/20240102-00/?p=109217
Basically bugs you can only exploit by already having root privileges don't really weaken your security at all
and https://vulnbrocards.com/, specifically VB002: No exploit from the heavens for when the attacker is already on the other side of the airtight hatchway
The LLM written replies on hackerone would have made me immediately disengage. Daniel is a far more patient man than me.
I find Daniel to be one of the most sensible open source maintainers out there. He has been vocal about the competition to assign silly CVEs', just so the finder can pad his/her CV.
LLVM keeps getting nonsense report, but just recently we had two that got CVEs.
This reported issues are not considered attack vectors under the llvm security policy -- if you're compiling untrusted code you're already doing everything an attacker needs.
But in addition to that, the reporter directly filed the CVEs, and reported that we had ignored the security bug report.
Neither had been filed (or even tagged) as security bugs, neither showed any attempt to contact anyone else. They were just two completely normal bug reports that a person wanted to get CVE#s assigned to in order to resume pad.
But the fact that MITRE just took it at face value that
And then published all of the above as true has made it clear that their listings should be considered fiction without confirmation from the affected project.
It also has the effect of notification fatigue: if there are constant pings and notifications about "security vulnerabilities" that are not actually security vulnerabilities it causes people to start ignore the notifications, and so miss real bugs.
Also all of these reporters of bugs want credit as if they did actual work: all they do is through an LLM and blindly report anything it finds with a note saying who to credit them as. There's no other interaction besides that. Well not quite true: some of them also have the LLM provide a "fix", which they also want credit for, and claim they have reviewed. I do not know what the idiots think "review" means, but it is not just 'does this compile and "fix" the bug report' -- the overwhelming majority of these automatic/vibe-coded PRs basically just de-fang assertions, or maybe add a null check. They don't work out why the assertion is firing, or what has gone wrong to lead to the broken state, they just make the crash go away.
I've seen their "I promise I have reviewed this PR and it is correct" where the test cases don't even trip the reported bugs, so then we have to waste time (1) looking at the PR to verify this is what they have done. Then (2) - if there is pushback - functionally diagnose the actual bug for them. There have been maybe two of these people who actually demonstrated an interest in learning how to actually develop software, and they've made huge progress. But again, the overwhelming majority aren't interested in anything that involves actual skill or work.
For people who appear and make multiple PRs, I've learned there's no reason to do anything more at this point than to just look for the defang, ask why the assertion is wrong, and then ignore the PR if there's never a reply. Again: overwhelming major never respond as that requires work. The few that do respond, actually seem interested in learning, and I'd say 50% of them actually start investing time in learning - the other 50% seem to take it on board and may try to hang around but the reality is learning this kind of thing is time consuming, and that time may simply not be available, or they're still learning basics of programming and llvm is complicated. But I give them infinite credit compared to the bug spamming muppets.
All of this ignores of course the people who try to hide that they're just using LLMs for the entire thing, which is generally trivial to identify.
It is not possible to trick an application to use a dot prefixed arbitrary name as it will fail to resolve.
Hmm. It seems not to be the case today, but I could've sworn that in the past "http://.example.com/" would load up in a web browser (and even be treated as a distinct origin for cookies etc). The fact that it doesn't work any more could imply the old behaviour was considered wrong and/or dangerous, but I'm pretty sure it used to work like that regardless.
You might be thinking of http://example.com./ with a trailing dot
Daniel blogged about trailing dot issues recently too https://daniel.haxx.se/blog/2026/06/25/trailing-dots-are-the-worst/
That is crazy that someone would try to add the root domain to an IP address. I would just not expect that to work since it's forbidden by the spec.
Maybe this is completely naive but I would personally use carefully validated (certainly PBTed, maybe exhaustively/formally verified) newtypes for all this to head off this class of issues. This is harder to do in C, though (which is why I wouldn't use C).
Ah, yup, that was it!
It may be confusing, but it is expected behavior that you can use a fully-qualified domain name as a URL. Should it be considered an alias for the purposes of sessions, cookies, et al.? I don't have an answer, it seems the browser vendors said no.
Huh! I'm surprised that browsers don't normalize it out. I can think of uses for it but they are all… bad.
Can you ever get an x509 cert for a FQDN?
Can you ever get an x509 cert for a FQDN?
You can and should, though I just tried on a random akamai.com domain and it caused TLS to fail (it seems lobsters also breaks).
I can think of uses for it but they are all… bad.
I commonly use it since it breaks ad networks.
You can and should
Should, just so people using the FQDN get a working TLS connection? Or is there some other reason I'm not thinking of?
This kicked off a whole investigation with pushcx & co. on the IRC. It looks like all the big players do support the FQDN, but instead put a permanent redirect on it to their desired canonical name (google.com. -> google.com). Technically you can host a different app since the domain name is "different", but that can hurt SEO to have your site duplicated at two "different" domains.
Domains in certificates are always fully qualified and must not have a trailing dot.
If a domain isn’t fully qualified then it omits one or more trailing labels and depends on an implicit resolver search path. Trailing dots are not necessary for a domain to be fully qualified and are sometimes forbidden (as in certificates and email). Depending on the application, you can sometimes use a trailing dot to suppress the resolver search path and force the domain to be treated as an FQDN.
As well as the differing syntactic restrictions of all the various applications and protocols, the resolver can query several databases other than the DNS and many of them have no notion of a root zone.
The consequences of the resolver search path have been messy almost from the start. The resolver can tell the application what is the canonical name of the host, and thereby expand an unqualified name. But it lacks a distinction between search-path canonicalization and CNAME canonicalization.
One of the awkwardnesses of the www is that it was the second application (after email) to need a notion of virtual hosting, and the way that email decouples application domains from server hostnames didn’t work for any other application, including the web. The hacks that were used for adding virtual hosting to web servers raced ahead of the development of a generalized architecture for virtual hosting (SRV records and explicit server names in protocol handshakes), and the web was never properly retrofitted to tidy up the mess.
Part of the mess arose from the period in the mid-1990s when unqualified hostnames were still popular, and the web was transitioning from IP-based to name-based virtual hosting. Looking back from the present, it would have been nice if web servers of that period had got into the habit of redirecting browsers to their canonical hostnames; but at the time there were a lot of half-working setups that would have been broken by such redirects (eg, misconfigured split-brain DNS or completely non-working DNS). And TLS and cookies were not yet common enough to make strictly matching hostnames important.
By the time it became clear that canonicalization would have been a good idea, the web had gone through a long period of IE-induced ossification while at the same time growing enormously. So it became too difficult to clean up the mess.
(I think web servers should be more eager to redirect clients to canonical hostnames, rather than leaving it to individual webmasters to fix; clients are in a more difficult situation, but as a rule I think it’s basically always wrong to put a trailing dot in a Host: header.)
((And these hostname syntax bugs in curl are the kinds of thing that can be fixed by “parse, don’t validate”; but I expect that pattern is hard for curl to implement because it’s dealing with a bunch of existing APIs that push it into revalidating names in divergent ways.))
The one thing that I can see this happening a lot is misconfiguring buggy software. I.e. the software that will address things to subdomains, but those subdomains are not checked for validity. So a placeholder like https://<subdomain>.domain.com but the subdomain was e.g. not set or someone wiped the dB column by accident or some such. You can end up with such a URL.
But you still need to have issued a wildcard SSL for that thing.