Deep-Dive: Finding and fixing high-severity libcurl/curl vulnerabilities

Just a short time ago, the security and development communities were put on notice with an advisory from the curl Project’s lead developer, Daniel Stenberg, who dropped the unfortunate missive that a new version of curl - distributed October 11 - was released to address two high-impact security vulnerabilities, one of which he describes as "probably the worst curl security flaw in a long time."

A postmortem on Stenberg’s blog noted that affected versions of the curl library are susceptible to a Heap-based buffer overflow vulnerability, related to a legacy issue with the SOCKS5 proxy protocol in use since 2002.

With its usage as a command line tool dating all the way back to 1998, curl is widely regarded as a foundational pillar of the internet. With such a storied history and widespread use, it is a dependency that, if found to be vulnerable, could have ongoing implications for general cyber safety.

This incident shares similarities with the devastating Log4Shell attack in Log4j, another vulnerable dependency that is still being exploited almost two years later.
‍
>>> Test your knowledge right now with our curl Mission!‍

The vulnerability: Buffer Overflow

The exploit is detailed under CVE-2023-38545, and impacts curl versions 7.69.0 up to and including 8.3.0. The primary bug is a Heap-based Buffer Overflow vulnerability, with initial reports noting that successful exploitation could lead to a more devastating Remote Code Execution (RCE) attack. While this is a possible workflow for a threat actor, it is a rare use case rather than a given.

Perhaps the one saving grace to mitigate some of the risks is that the malicious communication must go through a SOCKS5 proxy, which is a relatively uncommon deployment.

Comparable to the curl exploit, let’s take a look at this Buffer Overflow explainer:

When curl is told to use a SOCKS5 proxy, it will pass on the hostname and have the proxy resolve it. However, if the hostname exceeds the 255 bytes limit, curl will resolve the hostname locally (as seen in the code snippet below: source).

In case there is a slow handshake between the client and proxy, it is possible that the long hostname is copied into the memory buffer instead of the (shorter) resolved address. The allocated memory portion only allows for a 255-byte value, so if it receives a value that exceeds this limit, the data will overflow the memory buffer’s boundaries.

>>> Try it out for yourself in this playable mission!

Buffer Overflow is a powerful attack vector, and one that can be prevalent in a lot of legacy programming languages. In this particular case, exploitation made way for a more serious and damaging attack in the form of RCE in some contexts, though this pathway remains uncommon and unlikely.

How can you mitigate Buffer Overflow risk?

At this stage, the highest priority remediation is to apply the patches to all vulnerable instances, with a reminder that the use of curl is so widespread, it may not necessarily be obvious or advertised that components of your system include the dependency in use. In that case, auditing and subsequent patching are required. 

In general, buffer overflow flaws can be mitigated by using a memory-safe language like Rust, however, as is the case with a sprawling project like curl, it isn’t practical to port to another language or rewrite on a whim. As Stenberg notes while discussing the potential to use and support more dependencies written in memory-safe languages - or the alternative of gradually replacing parts of curl piecemeal - “... development is… currently happening in a near glacial speed and shows with painful clarity the challenges involved. curl will remain written in C for the foreseeable future.” It is no small undertaking, and the security implications are immense.

Security mistakes can and will happen, and it’s not always possible to rely on scanners and tests to pick up every possible attack vector. Therefore, our greatest weapon in the fight against these bugs is a commitment to ongoing security awareness and skill-building.
‍

Want to learn more about how to write secure code and mitigate risk?

Try out our Heap Overflow challenge for free.

If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.