libcurl duphandle read out of bounds
====================================

Project cURL Security Advisory, November 5th 2014 -
[Permalink](http://curl.haxx.se/docs/adv_20141105.html)

VULNERABILITY
-------------

libcurl's function
[`curl_easy_duphandle()`](http://curl.haxx.se/libcurl/c/curl_easy_duphandle.html)
has a bug that can lead to libcurl eventually sending off sensitive data that
was not intended for sending.

When doing an HTTP POST transfer with libcurl, you can use the
`CURLOPT_COPYPOSTFIELDS` option to specify a memory area holding the data to
send to the remote server. The memory area's size is set with a separate
option, for example `CURLOPT_POSTFIELDSIZE`.

As the name implies, the data in the specified buffer is copied to a privately
held memory buffer that libcurl allocates on the heap. The memory area is
associated with the common CURL handle, often referred to as an "easy handle".

This handle can be duplicated by an application to create an identical copy,
and all the already set options and data is then also similarly cloned and
will be associated with the newly returned handle. This also includes the data
to send in an HTTP POST request.

The internal libcurl function that duplicates options from the old handle to
the new, mistakenly treated the post data buffer as if it was a C string. A C
string ends with a zero byte, and subsequently strdup() was used to duplicate
the post data buffer. A post data buffer can perfectly legitimately contain a
zero byte, or it may not contain any zero byte at all (including no trailing
one) - leading to strdup() either making a too small duplicate, a too large
one or crash due to reading an inaccessible memory area. The strdup() of
course allocates memory off the heap.

If strdup finds a zero before the end of the buffer, the copied string ends up
shorter than the original buffer but the original buffer size is still kept
around. When libcurl subsequently constructs the HTTP POST request and
includes data for the protocol body it will memcpy() data from that new
pointer using the old size. This makes a read outside of the allocated
boundary and can thus lead to libcurl inserting data into the request that
happens to be laid out in the heap memory immediately after the post data
buffer.

We are not aware of anyone having been able to actually exploit this for
nefarious purposes, but we can't exclude that it is possible or even might
already have been exploited.

INFO
----

This bug requires `CURLOPT_COPYPOSTFIELDS` and `curl_easy_duphandle()` to be
used in that order, and then the duplicate handle must be used to perform the
HTTP POST.

The curl tool is not affected, it does not use this sequence.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2014-XXXX to this issue.

AFFECTED VERSIONS
-----------------

This bug has existed since `CURLOPT_COPYPOSTFIELDS` was introduced.

- Affected versions: from libcurl 7.17.1 to and including 7.38.0
- Not affected versions: libcurl >= 7.39.0

libcurl is used by many applications, but not always advertised as such!

THE SOLUTION
------------

libcurl 7.39.0 makes sure that the buffer area is duplicated and presumed to
be binary.

A patch for this problem is available at:

     http://curl.haxx.se/libcurl-copypostfields-preliminary.patch

RECOMMENDATIONS
---------------

We suggest you take one of the following actions immediately, in order of
preference:

A - Upgrade to curl and libcurl 7.39.0

B - Apply the patch and rebuild libcurl

C - Avoid using `CURLOPT_COPYPOSTFIELDS` then `curl_easy_duphandle()`

TIME LINE
---------

It was first reported to the curl project on September 16th 2014.

We contacted distros@openwall on October 20.

libcurl 7.39.0 was released on November 5th 2014, coordinated with the
publication of this advisory.

CREDITS
-------

Reported by Symeon Paraschoudis. Stas Malyshev helped us understand and repeat
the problem. Dan Fandrich helped assess the security risk. Patch written by
Daniel Stenberg.

Thanks a lot!


--

  / Daniel - curl lead developer