Last week, Daniel Stenberg announced that he would release a new version of the curl library and command line tool today, fixing a significant vulnerability. Curl is the de-facto standard library to create HTTP requests unless you still use Perl (good old LWP..). A significant vulnerability in curl will affect pretty much anything connecting to a web server. With everything becoming an HTTP-based API, code using curl is probably written faster than ever, and Daniel's work is more important than ever.

Today, we got the promised fix for CVE-2023-38545. So here is a quick overview of how severe it is:

The vulnerability is a heap-based buffer overflow, which may lead to arbitrary code execution. Modern operating systems should make exploitation of heap-based buffer overflows more difficult, but exploitation is possible.

To exploit this vulnerability, the attacker has to be able to supply an oversized hostname to curl. Host names passed to curl should be validated, and I do not believe such an oversized hostname would pass input validation. Sure, an attacker can run "curl" on the command line, but if they can do so, they already have code execution capabilities. A valid exploit would require an attacker to trigger code execution by, for example, passing a hostname to a web app that would trigger the code execution in curl.

Next, the exploit only exists if curl is used to connect to a SOCKS5 proxy. This is another dependency, making exploitation less likely.

To summarize:

This is only a valid exploit if you take unvalidated data and create an HTTP request via a SOCKS5 proxy to a hostname created from the unvalidated data. My recommendation is to upgrade without haste.

I rate the probability of this happening in actual code as very low. If you accept data, not validate it, and just blindly pass it to libraries like curl, you will likely have other problems that are easier to exploit.

[1] https://curl.se/docs/CVE-2023-38545.html

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|