oss-security - CVE Request -- Dovecot -- Validate certificate's CN against requested remote server hostname when proxying

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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

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.