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"
The bug has been referenced in the following commit(s):
Author: Tobias Klausmann <email@example.com>
AuthorDate: 2019-02-07 12:31:04 +0000
Commit: Tobias Klausmann <firstname.lastname@example.org>
CommitDate: 2019-02-07 12:31:19 +0000
net-misc/curl-7.64.0-r0: alpha stable
Signed-off-by: Tobias Klausmann <email@example.com>
net-misc/curl/curl-7.64.0.ebuild | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
arm stable, all arches done.
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.
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).