Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 18 Feb 2014 09:03:09 -0500 (EST)
Subject: Re: CVE request: "imapsync ignores the --tls switch and sends my authentication plaintext."

Hash: SHA1


There seems to be a possibility of at least two separate issues.
First, the product ends up trying a cleartext login even though
the --tls option is provided on the command line. This is assigned
CVE-2014-2014. (Moving to a cleartext session in reaction to a
certificate-verification failure would typically always be wrong for
any product.)

Second, the product is trying a cleartext login even though the server
sent LOGINDISABLED. RFC 3501 section 6.2.3 says "A client
implementation MUST NOT send a LOGIN command if the LOGINDISABLED
capability is advertised."

(The discussion also reported a third problem: "The user is never
notified of the certificate issue." That one is most likely, by
itself, outside the scope of CVE. If a product refused to operate in
an unsafe certificate situation, and did not tell the user why it was
refusing, that would potentially be a usability problem. That would
not be an independent vulnerability that could have a CVE ID.)

The patch in:

seems to change:

   $imap->starttls(  ) if ( $imap->Tls(  ) ) ;


   if ( $imap->Tls(  ) ) {
          $imap->starttls(  )
          or die_clean("Can not go to tls encryption on [$host]:", $imap->LastError, "\n" ) ;

in two places.

The second issue (proceeding when LOGINDISABLED is advertised) would
also be relevant if it occurred when the client did not include --tls
on the command line. If anyone has observed that, a second CVE ID
could be assigned. This is a protocol violation with security
implications. Compliant client software is supposed to look for
LOGINDISABLED in all cases, presumably including cases in which the
end user is not explicitly requesting a TLS session.

Finally, ends with

   there's still something weird, since I found that:
   --ssl1 --tls2 fails on host2 login with "Unable to start TLS: Cannot determine peer hostname for verification"
   --tls1 --tls2 succeeds
   --tls2 succeeds
   --tls1 --ssl2 succeeds

We couldn't immediately determine if that's simply a functionality
problem, or whether another vulnerability exists (e.g., if the correct
behavior were "fails" in all four cases, but with some combinations of
command-line options, there's no attempt to check a server hostname).

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ