Place your bets: a) logic bug b) memory bug (buffer overrun/use after free/etc) c) other
memory bug
Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
81–90 of 106 posts
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#82Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.
Silver lining: perhaps this will be exploitable for the purpose of jailbreaking and de-cloudifying various mobile hardware and IoT devices, which would otherwise become (or already are) expensive paperweights.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#83Earlier quoted context omitted.
And now the race has started with admins not being able to do anything. Anyone that knows of this vulnerability has enough time for a last hurray to exploit it as much as possible.
I don't agree. As an admin I can cordon off systems which might be exploited until the fix is released. If there's nothing to exploit, how can you exploit it?
Sure you can. Do you think slack can? Google can just down their entire fleet? Servers are an essential part of the world functioning. Curl is such a foundational library it's almost sure to be used in a large of part of existing servers.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#84Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.
Not to diminish the legacy of curl, but wget exists as well, right? Pretty sure a lot of machines use wget instead of curl.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#85Place your bets: a) logic bug b) memory bug (buffer overrun/use after free/etc) c) other
Or 1) SSL 2) HTTP/3 3) Other (DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP)
Fiver on 2)
Matches the "few years back"
Luckily HTTP/3 is so complex I doubt anyone could find the issue even if they looked :-)
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#86Earlier quoted context omitted.
I have the feeling that this is gonna be way bigger than the log4j mess.
Hmm. The worst case I can think of is if the vulnerability is exploitable before (or during) verification of TLS certificates for http(s). That would mean that someone in a MITM position would be able to inject the payload when libcurl make requests. But even that seems less messy than log4j? It can't possibly be as common that libcurl makes connections to arbitrary user entered urls, compared to log4j logging user e…
I thought so at first but then I remembered server side request forgery, SSRF
That's a bug class that is quite common but rarely leads to code exec or other issues (except in some cloud environments). If this is something that gives code exec after pointing curl at a malicious server it's going to be bad.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#87Ouch! Percentage of internet of things devices who don't ship libcurl is a rounding error. Percentage of internet of things devices that patch libcurl is also a rounding error.
Not to diminish the legacy of curl, but wget exists as well, right? Pretty sure a lot of machines use wget instead of curl.
wget is fine for downloading stuff, but I'm not sure how common its use for IoT is. curl has two distinct advantages:
- a library which can be linked to the application, i.e. one doesn't need to do the expensive fork()/exec[v[p[e]]]() dance and
- documentation: most cloud services offer examples using curl for their API. It takes some additional mental work to translate those into wget syntax.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#88Sad to see this just a month and a half from this post: https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... Is the CVE system unreasonably alarmistic or is C unpredictable with flaws?
The « issue » featured in this blog post was rated 9.8 critical when it wasn’t even a security issue.
That leaves just 9.9 and 10 for actual security issues like the one presented in GitHub issue.
When the severity scale goes from 9.8 to 10, yeah it’s unreasonably alarmist.
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#89Earlier quoted context omitted.
I have the feeling that this is gonna be way bigger than the log4j mess.
For the most part it's not common to be able to make a server call curl with an arbitrary server which is usually required to exploit this sort of thing. There will be some vulnerable apps, but the vast majority of servers with this vulnerability present won't be exploitable in any practical sense.
Sure. Or you can get an RCE on a car[0] after some bitsquatting[1].
[0] https://daniel.haxx.se/blog/2018/02/16/why-is-your-email-in-...
Re: Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11
#90Earlier quoted context omitted.
In this networked world, it really is a terrible language, there is no excuse for it The only authority this program should have is network access, some compute time and permission to create and write to one or more files. Nothing more. Though this is where almost all of our currently popular programming languages and operating systems are failing. They are fundamentally broken. Just on account of security, monolithi…
The issue is not that there’s no way to do this, it’s that there’s no portable way to do this. A seccomp bpf implementation of https://man.openbsd.org/pledge.2 could go a long way.
like https://github.com/jart/pledge?
i'm using this all over our production environment and it's very nice.