It still blows my mind that so many devices depend on a library largely written by a single person. The level of pressure must be insane and it shows in this bit:<p>"Reading the code now it is impossible not to see the bug. Yes, it truly aches having to accept the fact that I did this mistake without noticing and that the flaw then remained undiscovered in code for 1315 days. I apologize. I am but a human."<p>If Daniel happens to read this, thanks for your hard work, and I really don't think any apology is necessary. After all, the source was right there for any of us to read and review.
Very sensible conclusions about memory safety/memory-safe languages; excerpts follow.<p>---<p>Yes, this family of flaws would have been impossible if curl had been written in a memory-safe language instead of C [...]<p>The only approach in that direction I consider viable and sensible is to:<p>- allow, use and support more dependencies written in memory-safe languages and<p>- potentially and gradually replace parts of curl piecemeal, like with the introduction of hyper.<p>Such development is however currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.<p>Everyone not happy about this are of course welcome to roll up their sleeves and get working.<p>Including the latest two CVEs reported for curl 8.4.0, the accumulated total says that 41% of the security vulnerabilities ever found in curl would likely not have happened should we have used a memory-safe language. But also: the rust language was not even a possibility for practical use for this purpose during the time in which we introduced maybe the first 80% of the C related problems.<p>[...]<p>We repeatedly run several static code analyzers on the code and none of them have spotted any problems in this function.
This is a great writeup. However, even after also reading the CVE, I'm still unsure about under which circumstances you would be affected. As far as I understand it, you are affected if you<p>* use a SOCKS5 proxy, AND<p>* you use the SOCKS5 proxy to resolve hostnames (which AFAICS is NOT the default), AND<p>* the size of the buffer was changed from the default (100kb) to something below 65541 bytes, AND (EDIT: Not correct: 'libcurl' re-uses the download buffer for this, which by default is 16kB, however it is said that 'curl' itself sets it manually to 100kb UNLESS you use --limit-rate)<p>* the SOCKS5 proxy is too slow to handle the request immediately (which however, as the CVE states, can usually be provoked if the attacker has control over the request rate). (EDIT: This is wrong, the CVE actually says "Typical server latency is likely "slow" enough to trigger this bug without an attacker needing to influence it by DoS or SOCKS server control.")<p>So to me, the attack vector seems very small. Am I missing something?
I have to say this is the best CVE writeups I've ever read. And I can only commend the author who is humble throughout despite authoring one of the cornerstone software products of the age. Much respect.
<p><pre><code> if(!socks5_resolve_local && hostname_len > 255) {
socks5_resolve_local = TRUE;
}
</code></pre>
This is really a bad idea. For people who use anti-censorship tool to protect privacy, this can leak their identity through DNS.
> Yes, this family of flaws would have been impossible if curl had been written in a memory-safe language instead of C<p>It could have been impossible, but you never know if there is a way to escape language VM barriers. However, the author clearly ignored the DNS hostname limit stated in RFC1123 [1], which is hardcoded even in Java libraries.<p>[1] <a href="https://www.rfc-editor.org/rfc/rfc1123" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc1123</a>
This is a long and interesting note which could be reduced to "this is why system libraries need to be either written in a safe language or proved correct".<p>When one of the best, friendliest, and most transparent C programmers of our time is writing these posts, we need to pay attention.