cURL is one of the most widely-used command line and library tools for transferring data with URLs. It supports various protocols and is often found in backend systems, automation scripts, and even embedded devices. So when a security vulnerability hits it, especially one that lets an attacker crash your application or worse, people should pay attention.

One such bug is CVE-2022-43552, described as a "use after free" vulnerability in cURL before version 7.87..

This post breaks down how this bug works, why it’s dangerous, and walks through an example to help you understand whether you’re at risk.

What Is the Vulnerability?

A use after free bug means your code tries to use memory after it's been released (freed), which can lead to random crashes or, under some conditions, code execution.

cURL can be told to *tunnel* almost any protocol through an HTTP proxy (e.g., SMB, TELNET, FTP, etc.). Sometimes proxies reject tunnel requests — for example, if they don’t support the requested destination protocol.

When the proxy denies tunneling for SMB or TELNET, the shutdown code for cURL's transfers gets confused and tries to use a memory chunk it’s already released. That's where the problem happens.

References

- cURL CVE-2022-43552 advisory (official)
- GitHub patch commit
- NVD entry

Code Snippet: Where the Bug Lived

Let’s zoom into the area cURL tripped up. The vulnerable code flow looked something like this (highly simplified for illustration):

// In transfer.c (before version 7.87.)

if(command_denied && (protocol == SMB || protocol == TELNET)) {
    // ... do cleanup ...
    free(transfer_struct);
    // ... later ...
    log_info(transfer_struct->name); // <--- use after free!
}

In reality, the struct referenced various connection or transfer state, but you get the idea: after freeing the struct, cURL would access a field from it — which is now undefined memory.

Your curl invocation or your app using libcurl connects to SMB or TELNET via an HTTP proxy.

- The proxy denies the tunnel operation (for example, it responds with 403 Forbidden or an error code).

If all those are true, your program can unpredictably crash. In a server or automated system, this could mean denial of service, or, in rare cases, exploitable code execution (depends on luck, allocator, OS, and attacker enough control).

If your app doesn’t use SMB or TELNET proxies, or you never go through HTTP proxies, you’re probably safe.

Example terminal commands

# Start a dummy HTTP proxy on :3128

# Try to tunnel SMB through the proxy (assuming cURL <7.87.)
curl -v --proxy http://localhost:3128 smb://example.com/share

# Or TELNET:
curl -v --proxy http://localhost:3128 telnet://example.com/

If the proxy returns an error (like 407 or 403), cURL on susceptible versions may crash or show heap corruption warnings, depending on your libc and memory sanitizer options.

In fuzzing or code audit setting, you’ll see this leads to a use-after-free (detected by AddressSanitizer).

Patch & Fix

The cURL team fixed the bug by moving code around so the struct isn’t used after it’s freed. If you want to see the actual patch, check their commit:

- free(transfer_struct);
- log_info(transfer_struct->something); /* UAF! */
+ log_info(transfer_struct->something);
+ free(transfer_struct);

Upgrade your cURL or libcurl to version 7.87. or newer to stay safe.

Conclusion

- *CVE-2022-43552* affects cURL prior to 7.87. and involves UAF if SMB or TELNET tunnels are denied by the HTTP proxy.

If you don’t use these protocols or tunnel them via proxies, relax.

- But in shared hosting, scripts, or automation touching diverse protocols or unknown proxies, upgrade immediately.

Always keep your core tools and libraries up to date. Even the world’s most popular utilities sometimes slip up!

—  
For more details, read the cURL advisory, the NVD page, and stay patched.

Timeline

Published on: 02/09/2023 20:15:00 UTC
Last modified on: 03/28/2023 05:15:00 UTC