|
|
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:
> [1] http://www.dovecot.org/list/dovecot-news/2011-November/000200.html
> [2] https://secunia.com/advisories/46886/
> [3] https://bugs.gentoo.org/show_bug.cgi?id=390887
> [4] http://wiki.dovecot.org/PasswordDatabase/ExtraFields/Proxy
>
> Relevant upstream patch:
> [5] 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 [4]
> 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 [4]). 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.