Your message dated Mon, 10 Jun 2013 22:35:19 +0200
with message-id <1370896519.1380.19.camel@scapa>
and subject line closing bug already fixed a long time ago
has caused the Debian Bug report #649511,
regarding CVE-2011-4318
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
649511: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649511
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: dovecot
Severity: important
Tags: security
Please see the following summary from Red Hat's Jan Lieskovsky:
---------
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.
-------------
Also, please see Timo Sirainen's followup:
-------------
SSL proxy connections were added in some Dovecot v1.x version, but v1.x
doesn't support giving hostname as proxy destination, only IP address.
So this can't really be backported to v1.x.
My v2.0 change keeps this backwards compatible with existing setups that
use IP addresses, so that the hostname check is skipped when connecting
with IP.
Upcoming v2.1 is stricter and doesn't skip the check, which basically
means that ssl=yes with IP address as destination always fails.
-------------
We don't need to do anything wrt stable/oldstable, but please fix this
up for Wheezy.
Cheers,
Moritz
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Version: 1:2.0.18-1
Seems this one was never closed, so doing it now.
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
--- End Message ---
