CVE-2023-38546 - Exploiting Cookie Injection in libcurl via Easy Handle Duplication

Published: June 2024
Severity: Medium-High
Component: libcurl (7.9.1 to 8.3.)
Original Advisory: curl.se/security/advisory
Reference Doc: curl_easy_duphandle() API

Introduction

On October 11, 2023, the curl project disclosed CVE-2023-38546, a vulnerability that lets an attacker insert arbitrary cookies into applications using libcurl in some scenarios. The flaw doesn’t require deep Linux or network expertise to grasp — it revolves around an oddity in how libcurl handles cookie files upon duplicating "easy handles."

Let's break down how this happens, how an attacker can exploit it, and how developers can guard against this unusual bug.

What Is Happening Under the Hood?

libcurl is a popular C library that helps programs transfer data using various network protocols. The central concept in its API is the _easy handle_ (CURL *). Each handle represents one transfer (e.g., an HTTP request).

libcurl provides a function to duplicate an existing easy handle

CURL *curl_easy_duphandle(CURL *handle);

This allows an application to make a clean copy of a handle — copying all its options, including whether it’s set up to use cookies (with CURLOPT_COOKIEFILE or CURLOPT_COOKIEJAR).

Here’s where things go wrong

- If cookie loading is enabled for the original handle, but no actual cookie file is assigned (i.e., the handle was only told to "enable" cookies, not given a file or cookie string), then duplicating that handle leaves the duplicate with the cookie source set to the literal string none.
- If you then *use* this duplicated handle, libcurl will, by default, attempt to load a cookie file named none from the current working directory.
- If someone manages to place a file named none (with well-formed cookies) in the right spot, those cookies will be loaded into the app and sent with subsequent HTTP requests.

Diagram

Original easy handle  +  Cookies enabled (but no file)  +
 ↓ Duplicate           → Copy keeps "cookies enabled"    → 
                                                            File source becomes "none"
                                                            ↓
                                                        Loads 'none' from filesystem if available

Imagine a (vulnerable) simplified workflow in C

#include <curl/curl.h>

int main(void) {
    CURL *curl1 = curl_easy_init();
    curl_easy_setopt(curl1, CURLOPT_COOKIEFILE, ""); // Enable cookies without specifying file

    CURL *curl2 = curl_easy_duphandle(curl1); // Duplicate handle

    // ...curl2 now expects to load cookies from a file named 'none' if not specified otherwise!

    curl_easy_perform(curl2); // Will load and send cookies from './none' if it exists

    curl_easy_cleanup(curl1);
    curl_easy_cleanup(curl2);
    return ;
}

Real-World Exploit Scenario

Suppose you are running a web service or backend tool that uses libcurl easy handles and duplications for parallel requests — without specifying cookie files. An attacker who can place or trick the system into creating a file called none can get arbitrary cookies loaded by the next curl_easy_perform().

Place a file named none in the program's working directory

- This may happen through a prior exploit, unsafe file uploads, symlink tricks, or just an overlooked directory.

Netscape HTTP Cookie File

example.com TRUE / FALSE 2147483647 sessionid attackervalue

Don’t rely on the "just enable" mode (CURLOPT_COOKIEFILE, "") unless needed.

- After duplicating a handle, set the cookie file/path:

curl_easy_setopt(curl2, CURLOPT_COOKIEFILE, "your-cookie-file.txt");

`
- Upgrade libcurl to 8.4. or later, which patches this by never defaulting to the string "none."
- Restrict write/read permissions in the app's working directory to prevent attackers from dropping unexpected files.

See official patch:
- curl commit fixing CVE-2023-38546

---

## References & Further Reading

- Official Security Advisory – curl.se
- curl_easy_duphandle API docs
- libcurl Tutorial

---

## Summary

CVE-2023-38546 is a rare case where a common pattern (“duplicate the connection config for parallel requests”) unexpectedly exposes a classic local file injection route. If you use libcurl or ship software with it, double check your handle duplication and cookie logic to make sure your users aren’t exposed.

Upgrade now and always check your "none"!

---

> *Exclusive post by Assistant. Feel free to share or quote, and stay secure!*

Timeline

Published on: 10/18/2023 04:15:00 UTC
Last modified on: 10/28/2023 03:15:00 UTC