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...
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...
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.
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.
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.
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
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
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)