CVE-2018-16890: NTLM type-2 out-of-bounds buffer read CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow CVE-2019-3823: SMTP end-of-response out-of-bounds read
I added curl-7.64.0 to the tree and did preliminary testing. Its good for rapid stabilization. EYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
sparc stable
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07a5c573d80db48a01a46d12f7e7788232e2f1b5 commit 07a5c573d80db48a01a46d12f7e7788232e2f1b5 Author: Tobias Klausmann <klausman@gentoo.org> AuthorDate: 2019-02-07 12:31:04 +0000 Commit: Tobias Klausmann <klausman@gentoo.org> CommitDate: 2019-02-07 12:31:19 +0000 net-misc/curl-7.64.0-r0: alpha stable Bug: http://bugs.gentoo.org/677346 Signed-off-by: Tobias Klausmann <klausman@gentoo.org> net-misc/curl/curl-7.64.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arm64 stable
amd64 stable
x86 stable
ia64 stable
hppa stable
ppc64 stable
ppc stable
sh stable
arm stable
m68k stable
s390 stable
arm stable, all arches done.
CVE-2019-3823 (https://nvd.nist.gov/vuln/detail/CVE-2019-3823): libcurl versions from 7.34.0 to before 7.64.0 are vulnerable to a heap out-of-bounds read in the code handling the end-of-response for SMTP. If the buffer passed to `smtp_endofresp()` isn't NUL terminated and contains no character ending the parsed number, and `len` is set to 5, then the `strtol()` call reads beyond the allocated buffer. The read contents will not be returned to the caller. CVE-2019-3822 (https://nvd.nist.gov/vuln/detail/CVE-2019-3822): libcurl versions from 7.36.0 to before 7.64.0 are vulnerable to a stack-based buffer overflow. The function creating an outgoing NTLM type-3 header (`lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()`), generates the request HTTP header contents based on previously received data. The check that exists to prevent the local buffer from getting overflowed is implemented wrongly (using unsigned math) and as such it does not prevent the overflow from happening. This output data can grow larger than the local buffer if very large 'nt response' data is extracted from a previous NTLMv2 header provided by the malicious or broken HTTP server. Such a 'large value' needs to be around 1000 bytes or more. The actual payload data copied to the target buffer comes from the NTLMv2 type-2 response header.
This issue was resolved and addressed in GLSA 201903-03 at https://security.gentoo.org/glsa/201903-03 by GLSA coordinator Aaron Bauman (b-man).
