Date: Fri, 18 Nov 2011 14:37:04 +0100 From: Jan Lieskovsky <jlieskov@...hat.com> To: "Steven M. Christey" <coley@...us.mitre.org> CC: oss-security@...ts.openwall.com, Timo Sirainen <tss@....fi> Subject: CVE Request -- Dovecot -- Validate certificate's CN against requested remote server hostname when proxying Hello Kurt, Steve, vendors, a security flaw was found in the way Dovecot, an IMAP and POP3 email server, performed remote server identity verification (x509 certificate's Common Name field was not checked to match provided remote server host name), when Dovecot was configured to proxy IMAP and POP3 connections to remote hosts and TLS/SSL protocols were requested (ssl=yes or starttls=yes) in the configuration to secure these connections to the destination server. A remote attacker could use this flaw to conduct man-in-the-middle (MITM) attacks via specially- crafted x509v3 certificate. References:  http://www.dovecot.org/list/dovecot-news/2011-November/000200.html  https://secunia.com/advisories/46886/  https://bugs.gentoo.org/show_bug.cgi?id=390887  http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy Relevant upstream patch:  http://hg.dovecot.org/dovecot-2.0/rev/5e9eaf63a6b1 Could you allocate a CVE id for this? Note: This isn't a 'direct security flaw', in the sense it would be discovered / reported at some time point. This behaviour (do not check x509v3 cert CN against remote server hostname), when TLS/SSL protocols are configured, and the danger of MITM is already described on relevant Dovecot's page: http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy thus one could say, for those administrators, who are aware of  page and configured Dovecot in safe way there is no trust boundary crossing and this upstream change is just security hardening. But on the other hand, this change is important enough, to be backported to all affected versions, (regardless to the fact if particular administrator has or hasn't read ). Thus I would vote for a CVE identifier to be assigned to this issue. But opened for discussion if someone else (MITRE?) thinks this should be dealt with rather as with security hardening, than with a real security flaw. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.