Re: CVE request: "imapsync ignores the --tls switch and sends my authentication plaintext."

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> https://github.com/imapsync/imapsync/issues/15

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:

  https://github.com/imapsync/imapsync/commit/7d2043f95f42122c2ae3340053f893095efe1550

seems to change:

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

to:

   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, https://github.com/imapsync/imapsync/issues/15 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJTA2caAAoJEKllVAevmvmsjh0IAIfLB/+evn3Cb3/MXfe3h+W2
K2IUwXZACCqEx2jXOKzc3bG2ns3YlVzkvtxtmzZ0Vg6KAPb/SKEki4szcwu+hPbI
KCKRBGJR6Q/+42VGyks+56WtRoG7YhaAA7lhldULpzsXBaSvqe3pcuC1MGx2J1LL
Zia+++79c7JySlgXtMGc90/X2lKKYGdTgfKgWH3cmKTw0duNkA96i3QIeLm9ArUL
yYSEBsz5PFxeDBozFijIQUkf9cyjbHF9X5TIJkzL9UJ6U76qwMAUZelrAgFfHqVe
zoXMKCZKHzf5R1bhEjJU2V2cofp58JKX3rsKlVgupkBLIvaRU4beIAf1eGlESFw=
=aR5P
-----END PGP SIGNATURE-----