Attachment 145163 Details for Bug 221981 – Statement from mitr about the issues

Statement from mitr about the issues

mitr-mail-CVE-2006-5867.txt (text/plain), 2.84 KB, created by Lubomir Kundrak on 2007-01-09 14:16:31 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Lubomir Kundrak

Created: 2007-01-09 14:16:31 UTC

Size: 2.84 KB

patch

obsolete

>Hello,
>fetchmail-6.3.6 was released a few days ago, fixing CVE-2006-5867.  This
>is quite a mess (5 different issues in one CVE), and I'm not at all sure
>how to deal with it.  It is more a set of behavior changes than security
>fixes, although relevant to security, backporting any of the changes can
>break user's tested configurations.
>
>The upstream advisory is at
>http://www.fetchmail.info/fetchmail-SA-2006-02.txt .
>
>The mentioned issues are:
>> V1. sslcertck/sslfingerprint options should have implied "sslproto tls1"
>>     in order to enforce TLS negotiation, but did not.
>> V2. Even with "sslproto tls1" in the config, fetches would go ahead
>>     in plain text if STLS/STARTTLS wasn't available (not advertised,
>>     or advertised but rejected).
>doesn't affect RHEL2.1, which doesn't support STARTTLS/STLS
>affects RHEL[345], FC[56]
>
>These are really "fetchmail didn't support any way to enforce use of
>STARTTLS".  The documentation doesn't at all suggest sslcertck or
>sslfingerprint imply "SSL encryption required".  As for "sslproto tls1",
>its original meaning was "use TLS1 on imaps or pop3s connections (which
>don't use STARTTLS)", even when STARTTLS was not supported at all; using
>it to mean "if imaps or pop3s is not used, STARTTLS must succeed" is a
>new behavior in fetchmail-6.3.6.
>
>> V3. POP3 fetches could completely ignore all TLS options whether
>>     available or not because it didn't reliably issue CAPA before
>>     checking for STLS support - but CAPA is a requisite for STLS.
>>     Whether or not CAPAbilities were probed, depended on the "auth"
>>     option. (Fetchmail only tried CAPA if the auth option was not set at
>>     all, was set to gssapi, kerberos, kerberos_v4, otp, or cram-md5.)
>doesn't affect RHEL2.1, which doesn't support STARTTLS/STLS
>affects RHEL[345], FC[56]
>
>In addition, RHEL{2.1,3,4} are affected by a variant of this bug, where
>GSSAPI, KRBv4, CRAM-MD5 and OTP authentication on POP3 are performed
>only if CAPA is issued, and CAPA is issued only if the auth option is
>not set at all.  Thus, e.g. "auth gssapi" would _disable_ use of GSSAPI,
>and due to V4 cause plain-text authentication.
>
>> V4. POP3 could fall back to using plain text passwords, even if strong
>>     authentication had been configured.
>affects RHEL[345], FC[56]
>
>
>> V5. POP2 would not complain if strong authentication or TLS had been
>>     requested.
>affects RHEL[345], FC[56]
>
>A "don't do that" problem IMHO.
>
>
>So, my suggestions:
>* update rawhide - a nobrainer
>* update RHEL5 to 6.3.6, either for GA or as a zero-day update.
>  Enforcing STARTTLS usage is an important feature and we won't be able
>  to introduce the semantic changes into the release later.
>* FC[56]: update to 6.3.6, I guess.
>* RHEL<5: Ignore V1,V2,V5.  Fix V3,V4.
>  I'd like to both fix the possibilities of MITM attacks and avoid any
>  possibility of broken configurations, but we can't have both in these
>  cases.
>
>	Mirek
>
>

Actions: View

Attachments on bug 221981: 145163