1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
fetchmail-SA-2006-02: TLS enforcement problem/MITM attack/password exposure
Topics: fetchmail cannot enforce TLS
Author: Matthias Andree
Version: 1.0
Announced: 2006-11-XX
Type: secret information disclosure
Impact: fetchmail can expose cleartext password over unsecure link
fetchmail may not detect man in the middle attacks
Danger: medium
Credits: Isaac Wilcox (bug report, testing, collaboration on fix)
CVE Name: CVE-2006-5867
URL: http://fetchmail.berlios.de/fetchmail-SA-2006-02.txt
Project URL: http://fetchmail.berlios.de/
Affects: fetchmail releases <= 6.3.5
fetchmail release candidates 6.3.6-rc1, -rc2, -rc3
Not affected: fetchmail release candidate 6.3.6-rc4
fetchmail release 6.3.6
Corrected: 2006-11-26 fetchmail 6.3.6-rc4
0. Release history
==================
2006-11-16 v0.01 internal review draft
2006-11-26 v0.02 revise failure cases, workaround, add acknowledgments
1. Background
=============
fetchmail is a software package to retrieve mail from remote POP2, POP3,
IMAP, ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents.
fetchmail ships with a graphical, Python/Tkinter based configuration
utility named "fetchmailconf" to help the user create configuration (run
control) files for fetchmail.
2. Problem description and Impact
=================================
Fetchmail has no configuration facility to enforce TLS connections. This
can cause passwords to be sent over unencrypted channels in some cases:
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).
V3. POP3 fetches would completely ignore all TLS options whether
available or not because it didn't issue CAPA before checking
for STLS support.
This can cause eavesdroppers to obtain the password, depending on the
authentication scheme that is configured or auto-selected, and
subsequently impersonate somebody else when logging into the upstream
server.
3. Workarounds
==============
W1. If your upstream offers SSLv3-wrapped service on a dedicated port,
use fetchmail --ssl --sslcertck --sslproto ssl3 on the command line,
or equivalent in the run control file. This encrypts the whole session.
The next workarounds do not encrypt the channel, but get along without
password or mask it:
W2. If your upstream offers authentication schemes that don't require
cleartext credentials, use the --auth option to select a safe one, such
as Kerberos, GSSAPI, CRAM-MD5, or perhaps OTP.
W3. For POP3, if the upstream server supports APOP, you can use
--protocol apop to select APOP authentication.
4. Solution
===========
Download and install fetchmail 6.3.6 or a newer stable release from
fetchmail's project site at
<http://developer.berlios.de/project/showfiles.php?group_id=1824>.
5. Acknowledgments
==================
Isaac Wilcox has been a great help with testing the fixes and getting
them right.
A. Copyright, License and Warranty
==================================
(C) Copyright 2006 by Matthias Andree, <matthias.andree@gmx.de>.
Some rights reserved.
This work is licensed under the Creative Commons
Attribution-NonCommercial-NoDerivs German License. To view a copy of
this license, visit http://creativecommons.org/licenses/by-nc-nd/2.0/de/
or send a letter to Creative Commons; 559 Nathan Abbott Way;
Stanford, California 94305; USA.
THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.
END OF fetchmail-SA-2006-02.txt
|
