diff options
| -rw-r--r-- | NEWS | 10 | ||||
| -rw-r--r-- | fetchmail-SA-2012-02.txt | 31 | ||||
| -rw-r--r-- | ntlm.h | 4 | ||||
| -rw-r--r-- | ntlmsubr.c | 20 |
4 files changed, 47 insertions, 18 deletions
@@ -59,15 +59,19 @@ removed from a 6.4.0 or newer release.) fetchmail-6.3.22 (not yet released): # SECURITY FIXES -* CVE-2012-(not yet assigned): +* for CVE-2012-3482: NTLM: fetchmail mistook an error message that the server sent in response to an NTLM request for protocol exchange, tried to decode it, and crashed while reading from a bad memory location. - Fix: Detect base64 decoding errors and abort NTLM authentication. + Also, with a carefully crafted NTLM challenge packet sent from the server, it + would be possible that fetchmail conveyed confidential data not meant for the + server through the NTLM response packet. + Fix: Detect base64 decoding errors, validate the NTLM challenge, and abort + NTLM authentication in case of error. See fetchmail-SA-2012-02.txt for further details. Reported by J. Porter Clark. -* CVE-2011-3389: +* for CVE-2011-3389: SSL/TLS (wrapped and STARTTLS): fetchmail used to disable a countermeasure against a certain kind of attack against cipher block chaining initialization vectors (SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS). diff --git a/fetchmail-SA-2012-02.txt b/fetchmail-SA-2012-02.txt index 584706da..fc713d22 100644 --- a/fetchmail-SA-2012-02.txt +++ b/fetchmail-SA-2012-02.txt @@ -1,15 +1,17 @@ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 -fetchmail-SA-2012-02: DoS possible with NTLM authentication in debug mode +fetchmail-SA-2012-02: DoS/data theft possible in NTLM authentication -Topics: fetchmail denial of service in NTLM protocol phase +Topics: fetchmail denial of service/data theft in NTLM protocol phase Author: Matthias Andree Version: draft Announced: 2012-08-13 -Type: crash while reading from bad memory location -Impact: fetchmail segfaults and aborts, stalling inbound mail +Type: reading from bad memory locations +Impact: fetchmail segfaults and aborts, stalling inbound mail, + or: fetchmail conveys data from bad locations, possibly + betraying confidential data Danger: low Acknowledgment: J. Porter Clark @@ -34,6 +36,7 @@ Corrected in: 2012-08-13 Git, among others, see commit 2012-08-13 0.1 draft 2012-08-14 0.2 added CVE ID +2012-08-14 0.3 mention data theft 1. Background @@ -53,12 +56,16 @@ regular protocol ports. Fetchmail version 5.0.8 added NTLM support. This code sent the NTLM authentication request, but never checked if the received response was -NTLM protocol exchange, or a server-side error message. Instead, -fetchmail tried to decode the error message as though it were -base64-encoded protocol exchange, and could then segfault, subject to -verbosity and other circumstances, while reading data from bad memory -locations. +an NTLM challenge, or a server-side error message. Instead, fetchmail +tried to decode the error message as though it were base64-encoded +protocol exchange, and could then segfault, subject to verbosity and +other circumstances, while reading data from bad memory locations. +Also, when the "Target Name" structure in the NTLM Type 2 message (the +challenge) was carefully crafted, fetchmail might read from the wrong +memory location, and send confidential data to the server that it should +not have. It is deemed hard, although not impossible, to steal +other accounts' data. 3. Solution =========== @@ -106,7 +113,7 @@ END of fetchmail-SA-2012-02 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) -iEYEARECAAYFAlAp5g0ACgkQvmGDOQUufZXtLwCg54tPXJZAXauGxJ77oRGox49g -WUIAnizjQ4AvBSzk3Oraqv+WCS+8wiMb -=NEZ4 +iEYEARECAAYFAlAqnJ0ACgkQvmGDOQUufZURKQCgtarBW3fr0uR/ANpNma7QiAd0 +dFMAoPMNVYwTitZG/gkvwhr7QBGB59pj +=HBRo -----END PGP SIGNATURE----- @@ -32,8 +32,8 @@ uint32 msgType; tSmbStrHeader uDomain; uint32 flags; uint8 challengeData[8]; -uint8 reserved[8]; -tSmbStrHeader emptyString; +uint32 context[2]; +tSmbStrHeader targetInfo; uint8 buffer[1024]; uint32 bufIndex; }tSmbNtlmAuthChallenge; @@ -55,7 +55,8 @@ int ntlm_helper(int sock, struct query *ctl, const char *proto) if ((result = gen_recv(sock, msgbuf, sizeof msgbuf))) goto cancelfail; - if ((result = from64tobits (&challenge, msgbuf, sizeof(challenge))) < 0) + if ((result = from64tobits (&challenge, msgbuf, sizeof(challenge))) < 0 + || result < ((void *)&challenge.context - (void *)&challenge)) { report (stderr, GT_("could not decode BASE64 challenge\n")); /* We do not goto cancelfail; the server has already sent the @@ -64,6 +65,23 @@ int ntlm_helper(int sock, struct query *ctl, const char *proto) return PS_AUTHFAIL; } + /* validate challenge: + * - ident + * - message type + * - that offset points into buffer + * - that offset + length does not wrap + * - that offset + length is not bigger than buffer */ + if (0 != memcmp("NTLMSSP", challenge.ident, 8) + || challenge.msgType != 2 + || challenge.uDomain.offset > result + || challenge.uDomain.offset + challenge.uDomain.len < challenge.uDomain.offset + || challenge.uDomain.offset + challenge.uDomain.len > result) + { + report (stderr, GT_("NTLM challenge contains invalid data.\n")); + result = PS_AUTHFAIL; + goto cancelfail; + } + if (outlevel >= O_DEBUG) dumpSmbNtlmAuthChallenge(stdout, &challenge); |