Date: Fri, 18 Nov 2011 09:35:32 -0700 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com CC: Jan Lieskovsky <jlieskov@...hat.com>, "Steven M. Christey" <coley@...us.mitre.org>, Timo Sirainen <tss@....fi> Subject: Re: CVE Request -- Dovecot -- Validate certificate's CN against requested remote server hostname when proxying On 11/18/2011 06:37 AM, Jan Lieskovsky wrote: > 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 Please use CVE-2011-4318 for this issue. -- -Kurt Seifried / 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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ