Bug 1154941 (CVE-2014-3707)

Summary: CVE-2014-3707 curl: incorrect handle duplication after COPYPOSTFIELDS
Product: [Other] Security Response Reporter: Murray McAllister <mmcallis>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: acathrow, anemec, bazulay, bmcclain, carnil, cfergeau, dblechte, erik-fedora, gklein, idith, iheim, kdudka, lsurette, michal.skrivanek, paul, rbalakri, rh-spice-bugs, security-response-team, sisharma, slawomir, srevivo, weli, ykaul
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-11 09:04:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1160724, 1160725, 1175776, 1215062    
Bug Blocks: 1154942, 1193283, 1210268    
Attachments:
Description Flags
preliminary patch from upstream none

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 8 Tomas Hoger 2014-11-05 13:47:59 UTC 
Upstream commit:

https://github.com/bagder/curl/commit/b3875606925536f82fc61f3114ac42f29eaf6945
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