gzip integer overflow
App Store. A permissions issue was addressed with additional restrictions.
Accessibility. A privacy issue was addressed with improved private data redaction for log entries.
Accessibility. A privacy issue was addressed with improved private data redaction for log entries.
An authentication bypass vulnerability exists in libcurl prior to v8.0.0 where it reuses a previously established SSH connection despite the fact that an SSH option was modified which should have prevented reuse. libcurl maintains a pool of previously used connections to reuse them for subsequent transfers if the configurations match. However two SSH settings were omitted from the configuration check allowing them to match easily potentially leading to the reuse of an inappropriate connection.
A double free vulnerability exists in libcurl <8.0.0 when sharing HSTS data between separate "handles". This sharing was introduced without considerations for do this sharing across separate threads but there was no indication of this fact in the documentation. Due to missing mutexes or thread locks two threads sharing the same HSTS data could end up doing a double-free or use-after-free.
An authentication bypass vulnerability exists in libcurl <8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However certain FTP settings such as CURLOPTFTPACCOUNT CURLOPTFTPALTERNATIVETOUSER CURLOPTFTPSSLCCC and CURLOPTUSESSL were not included in the configuration match checks causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer potentially allowing unauthorized access to sensitive information.
An authentication bypass vulnerability exists libcurl <8.0.0 in the connection reuse feature which can reuse previously established connections with incorrect user permissions due to a failure to check for changes in the CURLOPTGSSAPIDELEGATION option. This vulnerability affects krb5/kerberos/negotiate/GSSAPI transfers and could potentially result in unauthorized access to sensitive information. The safest option is to not reuse connections if the CURLOPTGSSAPIDELEGATION option has been changed.
curl. Multiple issues were addressed by updating to curl version 7.79.1.
A flaw was found in libcurl in the way libcurl handles previously used connections without accounting for 'issuer cert' and comparing the involved paths case-insensitively. This flaw allows libcurl to use the wrong connection. The highest threat from this vulnerability is to confidentiality.
curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.
A flaw was found in the way libcurl handled TLS 1.3 session tickets. A malicious HTTPS proxy could possibly use this flaw to make libcurl resume a TLS session it previously had with the proxy while intending to resume a TLS session with a target server, making it possible for the proxy to perform a man-in-the-middle attack.
A flaw was found in libcurl from versions 7.29.0 through 7.71.1. An application that performs multiple requests with libcurl's multi API, and sets the CURLOPTCONNECTONLY option, might experience libcurl using the wrong connection. The highest threat from this vulnerability is to data confidentiality.
curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.
curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.
A heap buffer overflow in the TFTP receiving code allows for DoS or arbitrary code execution in libcurl versions 7.19.4 through 7.64.1.
curl and libcurl before 7.50.1 do not prevent TLS session resumption when the client certificate has changed, which allows remote attackers to bypass intended restrictions by resuming a session.
curl and libcurl before 7.50.1 do not check the client certificate when choosing the TLS connection to reuse, which might allow remote attackers to hijack the authentication of the connection by leveraging a previously created connection with a different client certificate.
A use-after-free vulnerability in libcurl was found. libcurl works with easy handles using the type 'CURL ' that are objects the application creates using curleasyinit(). They are the handles that are all each associated with a single transfer at a time. libcurl also has an internal struct that represents and holds most state that is related to a single connection. An easy handle can hold references to one or many such connection structs depending on the requested operations.
When using libcurl's multi interface, an application performs transfers by adding one or more easy handles to the multi handle and then it can drive all those transfers in parallel.
Due to a flaw, libcurl could leave a pointer to a freed connection struct dangling in an easy handle that was previously added to a multi handle when curlmulticleanup() is called with an easy handle still added to it. This does not seem to cause any notable harm if the handle is then closed properly.
However, if the easy handle would instead get used again with the easy interface and curleasyperform() to do another transfer, it would blindly use the connection struct pointer now pointing to freed memory.
An application could be made to allocate its own fake version of the connect struct, fill in some data and then have the curleasyperform() call do something that clearly was not intended by the original code.
External Reference:
https://curl.haxx.se/docs/adv20160803C.html
curl before version 7.61.1 is vulnerable to a buffer overrun in the NTLM authentication code. The internal function Curlntlmcoremknthash multiplies the length of the password by two (SUM) to figure out how large temporary storage area to allocate from the heap. The length value is then subsequently used to iterate over the password and generate output into the allocated storage buffer. On systems with a 32 bit sizet, the math to calculate SUM triggers an integer overflow when the password length exceeds 2GB (2^31 bytes). This integer overflow usually causes a very small buffer to actually get allocated instead of the intended very huge one, making the use of that buffer end up in a heap buffer overflow. (This bug is almost identical to CVE-2017-8816.)
curl. An out-of-bounds read issue existed in the FTP PWD response parsing. This issue was addressed with improved bounds checking.
An IMAP FETCH response line indicates the size of the returned data, in number of bytes. When that response says the data is zero bytes, libcurl would pass on that (non-existing) data with a pointer and the size (zero) to the deliver-data function.
libcurl's deliver-data function treats zero as a magic number and invokes strlen() on the data to figure out the length. The strlen() is called on a heap based buffer that might not be zero terminated so libcurl might read beyond the end of it into whatever memory lies after (or just crash) and then deliver that to the application as if it was actually downloaded.
Introduced with:
https://github.com/curl/curl/commit/ec3bb8f727
External References:
https://curl.haxx.se/docs/adv20171023.html
curl and libcurl 7.27.0 through 7.35.0, when running on Windows and using the SChannel/Winssl TLS backend, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate when accessing a URL that uses a numerical IP address, which allows man-in-the-middle attackers to spoof servers via an arbitrary valid certificate.
The default configuration in cURL and libcurl 7.10.6 before 7.36.0 re-uses (1) SCP, (2) SFTP, (3) POP3, (4) POP3S, (5) IMAP, (6) IMAPS, (7) SMTP, (8) SMTPS, (9) LDAP, and (10) LDAPS connections, which might allow context-dependent attackers to connect as other users via a request, a similar issue to CVE-2014-0015.
cURL and libcurl 7.1 before 7.36.0, when using the OpenSSL, axtls, qsossl or gskit libraries for TLS, recognize a wildcard IP address in the subject's Common Name (CN) field of an X.509 certificate, which might allow man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.
cURL and libcurl 7.10.6 through 7.34.0, when more than one authentication method is enabled, re-uses NTLM connections, which might allow context-dependent attackers to authenticate as other users via a request.
The GnuTLS backend in libcurl 7.21.4 through 7.33.0, when disabling digital signature verification (CURLOPTSSLVERIFYPEER), also disables the CURLOPTSSLVERIFYHOST check for CN or SAN host name fields, which makes it easier for remote attackers to spoof servers and conduct man-in-the-middle (MITM) attacks.
curl. An out-of-bounds read was addressed with improved bounds checking.
The URL percent-encoding decode function in libcurl before 7.51.0 is called curleasyunescape. Internally, even if this function would be made to allocate a unscape destination buffer larger than 2GB, it would return that new length in a signed 32 bit integer variable, thus the length would get either just truncated or both truncated and turned negative. That could then lead to libcurl writing outside of its heap based buffer.
After testing original CVE-2016-5420 patch, it was discovered that libcurl built on top of NSS (Network Security Services) still incorrectly re-uses client certificates if a certificate from file is used for one TLS connection but no certificate is set for a subsequent TLS connection.
The original patch for CVE-2016-5420 has been amended to also contain the attached patch:
https://curl.haxx.se/CVE-2016-5420.patch