Incoming details.
NTLM buffer overflow via integer overflow (CVE-2017-8816) libcurl contains a buffer overrun flaw in the NTLM authentication code. The internal function Curl_ntlm_core_mk_ntlmv2_hash sums up the lengths of the user name + password (= SUM) and multiplies the sum by two (= SIZE) to figure out how large storage to allocate from the heap. The SUM value is subsequently used to iterate over the input and generate output into the storage buffer. On systems with a 32 bit size_t, the math to calculate SIZE triggers an integer overflow when the combined lengths of the user name and password is larger than 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 buffer overrun. We are not aware of any exploit of this flaw. INFO This bug was introduced in commit 86724581b6c02d160b5, January 2014. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2017-8816 to this issue. AFFECTED VERSIONS This is only an issue on 32 bit systems. It also requires the user and password fields to use more than 2GB of memory combined, which in itself should be rare. Affected versions: libcurl 7.36.0 to and including 7.56.1 Not affected versions: libcurl < 7.36.0 and >= 7.57.0 curl is used by many applications, but not always advertised as such. THE SOLUTION In libcurl version 7.57.0, the integer overflow is avoided. https://curl.haxx.se/docs/adv_2017-12e7.html FTP wildcard out of bounds read (CVE-2017-8817) libcurl contains a read out of bounds flaw in the FTP wildcard function. libcurl's FTP wildcard matching feature, which is enabled with the CURLOPT_WILDCARDMATCH option can use a built-in wildcard function or a user provided one. The built-in wildcard function has a flaw that makes it not detect the end of the pattern string if it ends with an open bracket ([) but instead it will continue reading the heap beyond the end of the URL buffer that holds the wildcard. For applications that use HTTP(S) URLs, allow libcurl to handle redirects and have FTP wildcards enabled, this flaw can be triggered by malicious servers that can redirect clients to a URL using such a wildcard pattern. We are not aware of any exploit of this flaw. INFO This bug was introduced in commit 0825cd80a62c, May 2010. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2017-8817 to this issue. AFFECTED VERSIONS Affected versions: libcurl 7.21.0 to and including 7.56.1 Not affected versions: libcurl < 7.21.0 and >= 7.57.0 curl is used by many applications, but not always advertised as such. THE SOLUTION In libcurl version 7.57.0, there's a better check for the end of the string. Additionally, the wildcard feature is turned off if the URL passed to libcurl is not using FTP(S), so a redirect to an FTP URL cannot trigger wildcard functionality. RECOMMENDATIONS We suggest you take one of the following actions immediately, in order of preference: A - Upgrade curl to version 7.57.0 B - Apply the patch to your version and rebuild C - Do not use CURLOPT_WILDCARDMATCH without carfully verifying the patterns used. https://curl.haxx.se/docs/adv_2017-ae72.html SSL out of buffer access (CVE-2017-8818) libcurl contains an out boundary access flaw in SSL related code. When allocating memory for a connection (the internal struct called connectdata), a certain amount of memory is allocated at the end of the struct to be used for SSL related structs. Those structs are used by the particular SSL library libcurl is built to use. The application can also tell libcurl which specific SSL library to use if it was built to support more than one. The math used to calculate the extra memory amount necessary for the SSL library was wrong on 32 bit systems, which made the allocated memory too small by 4 bytes. The last struct member of the last object within the memory area could then be outside of what was allocated. Accessing that member could lead to a crash or other undefined behaviors depending on what memory that is present there and how the particular SSL library decides to act on that memory content. Specifically the vulnerability is present if libcurl was built so that sizeof(long long *) < sizeof(long long) which as far as we are aware only happens in 32-bit builds. We are not aware of any exploit of this flaw. INFO This bug was introduced in commit 70f1db321a, July 2017. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2017-8818 to this issue. AFFECTED VERSIONS This is only an issue on systems with 32 bit pointers. (Technically, on systems where sizeof(long long *) < sizeof(long long).) Affected versions: libcurl 7.56.0 to and including 7.56.1 Not affected versions: libcurl < 7.56.0 and >= 7.57.0 curl is used by many applications, but not always advertised as such. THE SOLUTION In libcurl version 7.57.0, the allocation size is corrected. https://curl.haxx.se/docs/adv_2017-af0a.html
curl-7.57.0 is in the tree and can be rapid stabilized KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sparc x86"
x86 stable
Stable on alpha.
stable on ppc and ppc64
sparc stable (thanks to Rolf Eike Beer)
amd64 stable
hppa stable (thanks to Rolf Eike Beer)
arm stable
Added to an existing GLSA.
This issue was resolved and addressed in GLSA 201712-04 at https://security.gentoo.org/glsa/201712-04 by GLSA coordinator Thomas Deutschmann (whissi).
Re-opening for remaining architecture/cleanup.
(In reply to Thomas Deutschmann from comment #12) > Re-opening for remaining architecture/cleanup. ping @ia64.
ia64 stable
The vulnerable versions are off the tree.
All done, repository is clean.
