Zero-Byte Death: The libcurl IMAP Heap Leak

We all love curl. It is the Swiss Army knife of the internet, the duct tape of the backend, and the library that powers practically everything that talks to a network. But even giants stumble, and in October 2017, the giant stumbled over a single integer: Zero.

This isn't your typical buffer overflow where we smash the stack with a sledgehammer. This is a subtle logical flaw, a classic case of "developer convenience" backfiring spectacularly. The vulnerability, CVE-2017-1000257, resides in how libcurl handles IMAP data. Specifically, it involves a "magic number" convention that was arguably a ticking time bomb from the moment it was written.

The premise is simple: A malicious IMAP server sends a response saying, "Hey, here is an email body, and it is exactly 0 bytes long." Sounds harmless, right? In a sane world, the client would say, "Cool, empty email," and move on. In the world of libcurl 7.56.0, that zero was interpreted as a command to read uninitialized memory until the heat death of the universe (or a null byte).

To understand the bug, we have to look at lib/sendf.c. This file contains the function Curl_client_write, which is the central hub for delivering data from the network stack to the client application's callback function. The developers, in an attempt to be helpful, added a shortcut.

Here is the logic flaw in plain English: If the caller of the function passes a length of 0, the function assumes the caller was too lazy to calculate the length themselves and attempts to determine it using strlen(). This implies that the data pointer must be a null-terminated C-string.

> [!CAUTION] > The Cardinal Sin of C Programming > Never treat a raw binary network buffer as a C-string. Network buffers are slabs of heap memory that may contain null bytes, no null bytes, or purely random garbage.

The IMAP handler (lib/imap.c) didn't get the memo. When parsing a FETCH response, the protocol explicitly tells us the size of the body. If that size happens to be zero, the IMAP handler dutifully passes 0 to the write function. Instead of writing zero bytes, Curl_client_write sees the magic number and decides to measure the buffer using strlen(). Since the buffer is on the heap and not null-terminated, strlen() goes on a joyride, counting bytes deep into adjacent memory.

Let's look at the smoking gun. This is the vulnerable code in lib/sendf.c that existed for years before being caught. It is a textbook example of why "magic values" are dangerous in API design.

/* lib/sendf.c in vulnerable versions */
CURLcode Curl_client_write(struct connectdata *conn, int type, char *ptr, size_t len)
{
  struct Curl_easy *data = conn->data;
 
  /* THE ROOT CAUSE */
  if(0 == len)
    len = strlen(ptr); // <--- Triggers OOB Read
 
  DEBUGASSERT(type <= 3);
  /* ... proceeds to write 'len' bytes to the app ... */
}

And here is the trigger in lib/imap.c. The variable chunk comes directly from the parsed IMAP response {0}.

/* lib/imap.c */
static CURLcode imap_state_fetch_resp(struct connectdata *conn, int imapcode, imapstate instate)
{
    /* ... size parsed from server ... */
    chunk = (size_t)size; // size is 0
    
    /* Triggering the bug by passing chunk (0) */
    result = Curl_client_write(conn, CLIENTWRITE_BODY, pp->cache, chunk);
}

Because pp->cache is a reusable buffer for network data, it likely contains the raw response from the server followed by whatever garbage was left over from previous allocations. strlen reads past the end of the intended data, and Curl_client_write delivers that extra data to the application.

Exploiting this requires a malicious or compromised IMAP server. The goal isn't to crash the client (though that's a likely side effect); the goal is to leak memory. Here is how an attacker sets the trap:

1. The Setup: The victim connects to our evil IMAP server using a vulnerable libcurl version.
2. The Bait: The client asks for an email using the FETCH command.
3. The Switch: We respond with a valid IMAP response, but we set the body size to zero.

* 1 FETCH (BODY[] {0}
)

When libcurl processes this, it passes 0 to the write function. strlen() executes on the buffer. Since the buffer isn't zeroed out between requests (for performance reasons), and heap memory is messy, strlen will likely find a null byte somewhere further down the line—maybe 50 bytes away, maybe 5,000 bytes away.

The Payoff: The curl client "successfully" downloads the email. However, the application receives a body that isn't empty. It receives a blob of data containing fragments of other emails, authentication tokens, headers, or anything else residing in the heap adjacent to the network buffer. If the attacker repeats this process, they can map out significant portions of the client's memory.

Why should you care about a read overflow? It's not RCE, is it? Not directly. But in the modern exploitation landscape, information is power. This vulnerability defeats ASLR (Address Space Layout Randomization) by leaking memory addresses, and it compromises data confidentiality.

Imagine a PHP script using curl to sync emails. It processes the "email body" (the leaked heap data) and perhaps logs it, or stores it in a database. The attacker now has a persistent record of the victim's server memory.

In a worst-case scenario, if the application is multi-threaded or reuses handles, the leaked heap data could contain:

• TLS Private Keys (if adjacent in memory).
• HTTP Cookies or Session IDs from other requests.
• Credentials for other services (AWS keys, DB passwords).

The CVSS score of 9.1 reflects this severity. It is a high-impact confidentiality breach that is trivial to trigger if you control the server.

The remediation was swift. The curl maintainers didn't remove the magic number logic from Curl_client_write immediately (likely to avoid breaking other internal logic relying on it), but they patched the IMAP handler to stop poking the bear.

The fix, introduced in commit 13c9a9ded3ae, explicitly checks if the size is zero before calling the write function. If the size is zero, it essentially says, "Nothing to see here," and returns early.

   chunk = (size_t)size;
 
+  if(!chunk) {
+    /* no size, we're done with the data */
+    state(conn, IMAP_STOP);
+    return CURLE_OK;
+  }
   result = Curl_client_write(conn, CLIENTWRITE_BODY, pp->cache, chunk);

This simple if(!chunk) check prevents the control flow from ever reaching the dangerous strlen logic with a zero length. It effectively neutralizes the exploit vector for IMAP. For developers, the lesson is clear: Explicit is better than implicit. Do not rely on magic numbers to handle memory safety.