[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EC65F80.1020005@redhat.com>
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:
[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
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.
