[SECURITY AVISORY] curl: FTP shutdown response buffer overflow
FTP shutdown response buffer overflow = Project curl Security Advisory, May 16th 2018 - [Permalink](https://curl.haxx.se/docs/adv_2018-82c2.html) VULNERABILITY - curl might overflow a heap based memory buffer when closing down an FTP connection with very long server command replies. When doing FTP transfers, curl keeps a spare "closure handle" around internally that will be used when an FTP connection gets shut down since the original curl easy handle is then already removed. FTP server response data that gets cached from the original transfer might then be larger than the default buffer size (16 KB) allocated in the "closure handle", which can lead to a buffer overwrite. The contents and size of that overwrite is controllable by the server. This situation was detected by an assert() in the code, but that was of course only preventing bad stuff in debug builds. This bug is very unlikely to trigger with non-malicious servers. We are not aware of any exploit of this flaw. INFO This bug was introduced in April 2017 in [this commit](https://github.com/curl/curl/commit/e40e9d7f0decc79) when we introduced the use of increased buffer sizes for FTP. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2018-1000300 to this issue. CWE-122: Heap-based Buffer Overflow AFFECTED VERSIONS - - Affected versions: curl 7.54.1 to and including curl 7.59.0 - Not affected versions: curl < 7.54.1 and curl >= 7.60.0 libcurl is used by many applications, but not always advertised as such. THE SOLUTION In curl version 7.60.0, curl will return an error if this situation happens. A [patch for CVE-2018-1000300](https://curl.haxx.se/CVE-2018-1000300.patch) is available. RECOMMENDATIONS --- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.60.0 B - Apply the patch to your version and rebuild C - Avoing using FTP TIME LINE - It was reported to the curl project on March 22, 2018 We contacted distros@openwall on May 7, 2018. curl 7.60.0 was released on May 16 2018, coordinated with the publication of this advisory. CREDITS --- Detected by Dario Weisser. Patch by Daniel Stenberg. Thanks a lot! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
[RELEASE] curl 7.60.0
Hi! I'm happy and proud to tell you that curl 7.60.0 has now been packaged and released. This time, we're announcing two new security advisories in sync with this release. As always, get the latest release and all associated information from https://curl.haxx.se Curl and libcurl 7.60.0 Public curl releases: 174 Command line options: 214 curl_easy_setopt() options: 255 Public functions in libcurl: 74 Contributors: 1741 This release includes the following changes: o Add CURLOPT_HAPROXYPROTOCOL, support for the HAProxy PROXY protocol [10] o Add --haproxy-protocol for the command line tool [10] o Add CURLOPT_DNS_SHUFFLE_ADDRESSES, shuffle returned IP addresses [12] This release includes the following bugfixes: o FTP: shutdown response buffer overflow CVE-2018-1000300 [88] o RTSP: bad headers buffer over-read CVE-2018-1000301 [89] o FTP: fix typo in recursive callback detection for seeking [1] o test1208: marked flaky o HTTP: make header-less responses still count correct body size [2] o user-agent.d:: mention --proxy-header as well [3] o http2: fixes typo [4] o cleanup: misc typos in strings and comments [5] o rate-limit: use three second window to better handle high speeds [6] o examples/hiperfifo.c: improved o pause: when changing pause state, update socket state [7] o multi: improved pending transfers handling => improved performance [8] o curl_version_info.3: fix ssl_version description [9] o add_handle/easy_perform: clear errorbuffer on start if set [11] o darwinssl: fix iOS build [13] o cmake: add support for brotli [14] o parsedate: support UT timezone [15] o vauth/ntlm.h: fix the #ifdef header guard o lib/curl_path.h: added #ifdef header guard o vauth/cleartext: fix integer overflow check [16] o CURLINFO_COOKIELIST.3: made the example not leak memory o cookie.d: mention that "-" as filename means stdin [17] o CURLINFO_SSL_VERIFYRESULT.3: fixed the example [18] o http2: read pending frames (including GOAWAY) in connection-check [19] o timeval: remove compilation warning by casting [20] o cmake: avoid warn-as-error during config checks [21] o travis-ci: enable -Werror for CMake builds [22] o openldap: fix for NULL return from ldap_get_attribute_ber() [23] o threaded resolver: track resolver time and set suitable timeout values [24] o cmake: Add advapi32 as explicit link library for win32 [25] o docs: fix CURLINFO_*_T examples use of CURL_FORMAT_CURL_OFF_T [26] o test1148: set a fixed locale for the test [27] o cookies: when reading from a file, only remove_expired once [28] o cookie: store cookies per top-level-domain-specific hash table [29] o openssl: fix build with LibreSSL 2.7 [30] o tls: fix mbedTLS 2.7.0 build + handle sha256 failures [31] o openssl: RESTORED verify locations when verifypeer==0 [32] o file: restore old behavior for file:foo/bar URLs [33] o FTP: allow PASV on IPv6 connections when a proxy is being used [34] o build-openssl.bat: allow custom paths for VS and perl [35] o winbuild: make the clean target work without build-type [36] o build-openssl.bat: Refer to VS2017 as VC14.1 instead of VC15 [37] o curl: retry on FTP 4xx, ignore other protocols [38] o configure: detect (and use) sa_family_t [39] o examples/sftpuploadresume: Fix Windows large file seek o build: cleanup to fix clang warnings/errors [40] o winbuild: updated the documentation [41] o lib: silence null-dereference warnings [42] o travis: bump to clang 6 and gcc 7 [43] o travis: build libpsl and make builds use it [44] o proxy: show getenv proxy use in verbose output [45] o duphandle: make sure CURLOPT_RESOLVE is duplicated [46] o all: Refactor malloc+memset to use calloc [47] o checksrc: Fix typo [48] o system.h: Add sparcv8plus to oracle/sunpro 32-bit detection [49] o vauth: Fix typo [50] o ssh: show libSSH2 error code when closing fails [51] o test1148: tolerate progress updates better [52] o urldata: make service names unconditional [53] o configure: keep LD_LIBRARY_PATH changes local [54] o ntlm_sspi: fix authentication using Credential Manager [55] o schannel: add client certificate authentication [56] o winbuild: Support custom devel paths for each dependency [57] o schannel: add support for CURLOPT_CAINFO [58] o http2: handle on_begin_headers() called more than once [59] o openssl: support OpenSSL 1.1.1 verbose-mode trace messages [60] o openssl: fix subjectAltName check on non-ASCII platforms [61] o http2: avoid strstr() on data not zero terminated [62] o http2: clear the "drain counter" when a stream is closed [63] o http2: handle GOAWAY properly [64] o tool_help: clarify --max-time unit of time is seconds o curl.1: clarify that options and URLs can be mixed [65] o http2: convert an assert to run-time check [66] o curl_global_sslset: always provide available backends [67] o ftplistparser: keep state between invokes [68] o Curl_memchr: zero length input can't match o
Mozilla CA Certificates, UTF-8
Hi,
I have a question concerning the Mozilla CA Certificates bundle
encoding and a proposal for supporting in-memory certificates.
On this page:
https://curl.haxx.se/docs/caextract.html
it is possible to download one of several PEM files containing
the Mozilla CA Certificates bundle. In the current bundle,
https://curl.haxx.se/ca/cacert-2018-03-07.pem
two entries (lines 1171 and 2638 respectively) have comments that
are in UTF-8, which I noticed today, pasted below for reference:
1171: NetLock Arany (Class Gold) Főtanúsítvány
2638: TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
These are ignored [2], of course, but may cause problems in
programs that wish to parse or store this PEM file in other
formats. It is unclear / unspecified in [1] as to whether UTF-8
is acceptable.
Should these be converted [via 'mk-ca-bundle'], ignored [leave
the file as-is] or some other option?
My second question is, would there be any interest in having an
"in-memory" certificate option? I see an example [3] for OpenSSL,
but am considering adding something like 'ssl_camem' in addition
to 'ssl_cafile' and 'ssl_capath' [4], and the respective easy-opt
flag, perhaps 'CURLOPT_CAMEM' to specify a char * pointing to in-
memory contents of that CA file.
The file could either be read into memory or compiled, e.g., the
output of 'xxd -i'. If this may be of interest, let's discuss.
ZV
[1]: https://tools.ietf.org/html/rfc1421
[2]: https://tools.ietf.org/html/rfc7468
[3]: https://raw.githubusercontent.com/curl/curl/master/docs/exam
ples/cacertinmem.c
[4]: curl/lib/vtls/{mbedtls,openssl,polarssl,...}.c
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Mozilla CA Certificates, UTF-8
On Wed, 16 May 2018, Zach van Rijn wrote: two entries (lines 1171 and 2638 respectively) have comments that are in UTF-8, which I noticed today, pasted below for reference: ... Should these be converted [via 'mk-ca-bundle'], ignored [leave the file as-is] or some other option? I think that as long as nobody reports a problem with them being left as-is we can just let them be. Unless someone feels an urge to dig in and figure out what the "right" way forward is here. My second question is, would there be any interest in having an "in-memory" certificate option? I see an example [3] for OpenSSL, but am considering adding something like 'ssl_camem' in addition to 'ssl_cafile' and 'ssl_capath' [4], and the respective easy-opt flag, perhaps 'CURLOPT_CAMEM' to specify a char * pointing to in- memory contents of that CA file. I think there is an interest. This subject has been up before[1] and is also mentioned in the TODO [2]. I don't know how complicated this feature is to implement for other TLS backends than openssl (and its siblings boringssl/libressl). [1] = https://github.com/curl/curl/issues/2310 [2] = https://curl.haxx.se/docs/todo.html#Support_in_memory_certs_ca_certs -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
[SECURITY AVISORY] curl: RTSP bad headers buffer over-read
RTSP bad headers buffer over-read = Project curl Security Advisory, May 16th 2018 - [Permalink](https://curl.haxx.se/docs/adv_2018-b138.html) VULNERABILITY - curl can be tricked into reading data beyond the end of a heap based buffer used to store downloaded content. When servers send RTSP responses back to curl, the data starts out with a set of headers. curl parses that data to separate it into a number of headers to deal with those appropriately and to find the end of the headers that signal the start of the "body" part. The function that splits up the response into headers is called `Curl_http_readwrite_headers()` and in situations where it can't find a single header in the buffer, it might end up leaving a pointer pointing into the buffer instead of to the start of the buffer which then later on may lead to an out of buffer read when code assumes that pointer points to a full buffer size worth of memory to use. This could potentially lead to information leakage but most likely a crash/denial of service for applications if a server triggers this flaw. We are not aware of any exploit of this flaw. INFO This bug was originally introduced in May 2003 in [this commit](https://github.com/curl/curl/commit/b2ef79ef3d47b37) but it didn't become a problem until we added RTSP in January 2010 in [this commit](https://github.com/curl/curl/commit/bc4582b68a673d3). We have only proven this to trigger with RTSP traffic even though this is code shared with HTTP. We believe this is not a problem for HTTP transfers. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2018-1000301 to this issue. CWE-126: Buffer Over-read AFFECTED VERSIONS - - Affected versions: curl 7.20.0 to and including curl 7.59.0 - Not affected versions: curl < 7.20.0 and curl >= 7.60.0 libcurl is used by many applications, but not always advertised as such. THE SOLUTION In curl version 7.60.0, curl makes sure to restore the pointer back to where its supposed to point. A [patch for CVE-2018-1000301](https://curl.haxx.se/CVE-2018-1000301.patch) is available. RECOMMENDATIONS --- We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.60.0 B - Apply the patch to your version and rebuild TIME LINE - It was reported to the curl project on March 24, 2018 We contacted distros@openwall on May 7, 2018. curl 7.60.0 was released on May 16 2018, coordinated with the publication of this advisory. CREDITS --- Detected by OSS-fuzz. Assisted by Max Dymond. Patch by Daniel Stenberg. Thanks a lot! -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Mozilla CA Certificates, UTF-8
On Thu, 2018-05-17 at 00:51 +0200, Daniel Stenberg wrote: > On Wed, 16 May 2018, Zach van Rijn wrote: > > > ... > > I think that as long as nobody reports a problem with them > being left as-is we can just let them be. Unless someone feels > an urge to dig in and figure out what the "right" way forward > is here. > I asked in #cryptography on Freenode, and was told: * RFC 7468 says "Parsers MUST handle non-conforming data gracefully." * It explicitly says that "Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data", but nothing about data after the END line * There's also section 5.2, which notes that "Many tools are known to emit explanatory text before the BEGIN and after the END lines for PKIX certificates, more than any other type." (Side note: if anyone wishes to remove all of the labels and '===' lines from the PEM file I referenced earlier, one possibility is: "perl -p0e 's/.*\n=.*\n//g' -i cacert.pem"). So conclusively, the file on the website should be left intact. > > ... > I think there is an interest. This subject has been up > before[1] and is also mentioned in the TODO [2]. > > I don't know how complicated this feature is to implement for > other TLS backends than openssl (and its siblings > boringssl/libressl). > > [1] = https://github.com/curl/curl/issues/2310 > [2] = https://curl.haxx.se/docs/todo.html#Support_in_memory_cer > ts_ca_certs > From what I gather, mbedTLS should be straightforward but I've not looked at the others as I'm only using mbedTLS currently. Anyone else want to help with this? I think it would be nice to see this come to fruition. ZV --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
