Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1154941 (CVE-2014-3707) - CVE-2014-3707 curl: incorrect handle duplication after COPYPOSTFIELDS
Summary: CVE-2014-3707 curl: incorrect handle duplication after COPYPOSTFIELDS
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2014-3707
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1160724 1160725 1175776 1215062
Blocks: 1154942 1193283 1210268
TreeView+ depends on / blocked
 
Reported: 2014-10-21 05:12 UTC by Murray McAllister
Modified: 2019-09-29 13:23 UTC (History)
23 users (show)

Fixed In Version: curl 7.39.0
Doc Type: Bug Fix
Doc Text:
A flaw was found in the way the libcurl library performed the duplication of connection handles. If an application set the CURLOPT_COPYPOSTFIELDS option for a handle, using the handle's duplicate could cause the application to crash or disclose a portion of its memory.
Clone Of:
Environment:
Last Closed: 2016-07-11 09:04:18 UTC


Attachments (Terms of Use)
preliminary patch from upstream (10.18 KB, patch)
2014-10-21 05:14 UTC, Murray McAllister
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1254 normal SHIPPED_LIVE Moderate: curl security, bug fix, and enhancement update 2015-07-20 17:50:03 UTC
Red Hat Product Errata RHSA-2015:2159 normal SHIPPED_LIVE Moderate: curl security, bug fix, and enhancement update 2015-11-19 08:26:18 UTC

Description Murray McAllister 2014-10-21 05:12:02 UTC
Daniel Stenberg reported the following vulnerability in cURL:

""
libcurl's function curl_easy_duphandle() 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 had two problems:

1. It 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.

2. After duplication of the handle data, the pointer used to read from when
   sending the data was not updated. So when sending off the post, libcurl
   would still read from the original handle's buffer which at that time could
   have been freed or reused for other purposes.

When libcurl subsequently constructs the HTTP POST request and includes data
for the protocol body it will memcpy() data from that pointer using the old
size and the old pointer. This makes a read from the wrong place and can lead
to libcurl inserting data into the request that happens to be stored at that
places in memory at that time.

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.
"""

This issue affects versions 7.17.1 up to and including 7.38.0. It has been fixed in version 7.39.0

Acknowledgements:

Red Hat would like to thank the cURL project for reporting this issue. Upstream acknowledges Symeon Paraschoudis as the original reporter.

Comment 2 Murray McAllister 2014-10-21 05:14:16 UTC
Created attachment 948796 [details]
preliminary patch from upstream

Comment 5 Tomas Hoger 2014-10-24 19:45:47 UTC
This issue affects applications that set CURLOPT_COPYPOSTFIELDS options on a curl handle a subsequently duplicate the handle (using curl_easy_duphandle()).

During the handle duplication, libcurl may read memory outside of the bounds of allocated buffer if POST data set using CURLOPT_COPYPOSTFIELDS was not NUL terminated.  The out of bounds access occurs in strdup()/strlen().  This can cause crash if unmapped memory is reached before NUL byte is found, but such crash is unlikely.

Due to another bug in the handle duplication code, POST data in the copied handle is not used even if no new POST data are set before performing the request.  Instead, data from the buffer associated with the original handle is used.  Therefore, if the original handle is freed, or if new POST data is set on it between duplication and the use of the new handle, libcurl may use data from an already freed buffer.

There are no applications in Red Hat Enterprise Linux that uses libcurl in the way that would make them vulnerable to this issue.  The CURLOPT_COPYPOSTFIELDS option is only used by PHP, when PHP script sets CURLOPT_POSTFIELDS option with data that is not array or object.  As string arguments used with PHP curl_setopt(CURLOPT_POSTFIELDS) are unlikely to be NUL terminated, strdup() out of bounds read is likely to happen in curl_copy_handle().

Upstream advisory lists curl versions 7.17.1 and later to be affected by this problem.  The version 7.17.1 is the one that introduced the CURLOPT_COPYPOSTFIELDS option.  The curl packages in Red Hat Enterprise Linux 5 and earlier are based on older upstream curl versions and hence were not affected by this issue.

Comment 6 Martin Prpič 2014-11-05 10:47:33 UTC
This issue is now public.

External Reference:

http://curl.haxx.se/docs/adv_20141105.html

Comment 7 Kamil Dudka 2014-11-05 12:57:51 UTC
fixed in curl-7.39.0-1.fc22

fixed in curl-7.37.0-9.fc21

fixed in curl-7.32.0-15.fc20

fixed in curl-7.29.0-25.fc19

Comment 9 Tomas Hoger 2014-11-05 13:50:03 UTC
Created mingw-curl tracking bugs for this issue:

Affects: fedora-all [bug 1160724]
Affects: epel-7 [bug 1160725]

Comment 10 Fedora Update System 2014-11-10 06:43:29 UTC
curl-7.37.0-9.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Fedora Update System 2014-11-10 06:43:55 UTC
curl-7.32.0-15.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Vincent Danen 2014-11-12 21:24:53 UTC
Statement:

This issue does not affect the versions of curl as shipped with Red Hat Enterprise Linux 5.

Note that there are no applications provided with Red Hat Enterprise Linux that use the vulnerable CURLOPT_COPYPOSTFIELDS option, except PHP which could only be affected if used in an extremely unlikely scenario or via the script's author.

Comment 13 Fedora Update System 2014-12-01 18:56:46 UTC
curl-7.32.0-16.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2014-12-13 09:46:33 UTC
curl-7.32.0-17.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2014-12-15 04:28:15 UTC
curl-7.37.0-11.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2015-01-03 18:59:39 UTC
curl-7.29.0-27.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 errata-xmlrpc 2015-07-22 05:43:58 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2015:1254 https://rhn.redhat.com/errata/RHSA-2015-1254.html

Comment 23 errata-xmlrpc 2015-11-19 07:07:01 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:2159 https://rhn.redhat.com/errata/RHSA-2015-2159.html


Note You need to log in before you can comment on or make changes to this bug.