Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 145163 Details for
Bug 221981
CVE-2006-5867 fetchmail not enforcing TLS for POP3 properly
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
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:
Statement from mitr about the issues
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 > >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 221981
: 145163