[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EC68954.4030502@redhat.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
