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.
Created attachment 948796 [details] preliminary patch from upstream
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.
This issue is now public. External Reference: http://curl.haxx.se/docs/adv_20141105.html
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
Upstream commit: https://github.com/bagder/curl/commit/b3875606925536f82fc61f3114ac42f29eaf6945
Created mingw-curl tracking bugs for this issue: Affects: fedora-all [bug 1160724] Affects: epel-7 [bug 1160725]
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.
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.
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.
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.
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.
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.
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.
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
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