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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
fetchmail-SA-2021-02: failure to enforce STARTTLS session encryption
Topics: fetchmail fails to enforce an encrypted connection
Author: Matthias Andree
Version: 0.3
Announced: TBC
Type: failure to enforce configured security policy
Impact: fetchmail continues an unencrypted connection,
thus reading unauthenticated input and sending
information unencrypted over its transport,
including passwords
Danger: medium
Acknowledgment: Andrew C. Aitchison for reporting this against fetchmail
Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian
Schinzel for their Usenix Security 21 paper NO STARTTLS
CVE Name: TBC (if any)
URL: https://www.fetchmail.info/fetchmail-SA-2021-02.txt
Project URL: https://www.fetchmail.info/
Affects: - fetchmail releases up to and including 6.4.21
Not affected: - fetchmail releases 6.4.22 and newer
Corrected in: TBC Git commit hash (both needed)
TBC fetchmail 6.4.21 release tarball
0. Release history
==================
2021-08-10 initial report to maintainer
2021-08-10 0.1 first draft
2021-08-13 0.2 mention --auth ssh defeated STARTTLS
2021-08-14 0.3 mention POP3 RPA defeated STARTTLS, and
make explicit that --auth ssh applied to
IMAP and POP3 alike.
1. Background
=============
fetchmail is a software package to retrieve mail from remote POP3, IMAP,
ETRN or ODMR servers and forward it to local SMTP, LMTP servers or
message delivery agents. fetchmail supports SSL and TLS security layers
through the OpenSSL library, if enabled at compile time and if also
enabled at run time, in both SSL/TLS-wrapped mode on dedicated ports as
well as in-band-negotiated "STARTTLS" and "STLS" modes through the
regular protocol ports.
2. Problem description and Impact
=================================
fetchmail permits requiring that an IMAP or POP3 protocol exchange uses
a TLS-encrypted transport, in 6.4 by way of an --sslproto auto or similar
configuration.
This TLS encryption can be established either as implicit or fully-wrapped
connections on dedicated TCP ports for the "secure" variants, or by initiating
a clear-text protocol exchange and then requesting a TLS negotiation in-band.
IMAP also supports sessions that start in "authenticated state" (PREAUTH).
In this latter case, IMAP (RFC-3501) does not permit sending STARTTLS
negotiations, which are only permissible in not-authenticated state.
In such a combination of circumstances (1. IMAP protocol in use, 2. the
server greets with PREAUTH, announcing authenticated state, 3. the user
configured TLS mandatory, 4. the user did not configure "ssl" mode that uses
separate ports for implicit SSL/TLS), fetchmail 6.4.21 and older continues
with the unencrypted connection, rather than reporting and aborting.
A similar situation is encountered for POP3: if the remote name contains
@compuserve.com, the server supports a non-standard "AUTH" command without
mechanism argument and responds with a list that contains "RPA" (also in
mixed or lower case), then fetchmail will not attempt STARTTLS. While the
password itself is then protected by the RPA scheme (which employs MD5 however),
the session as a whole is not protected by TLS.
Also, a configuration containing --auth ssh (meaning that fetchmail should not
authenticate, on the assumption that the session will be pre-authenticated for
instance through SSH running a mail server with --plugin, or TLS client
certificates), will also defeat STARTTLS as result of an implementation defect.
This affected both POP3 and IMAP.
This can cause e-mail and in the first case, also potentially passwords, to be
exposed to eavesdropping.
3. Solutions
============
3a. Install fetchmail 6.4.22 or newer.
The fetchmail source code is available from
<https://sourceforge.net/projects/fetchmail/files/>.
The Git-based source code repository is currently published via
https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_64 (primary)
https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/ (copy)
3b. Alternatively, where the IMAP or POP3 server supports this form of access,
fetchmail can be configured to "ssl" mode, meaning it will connect to
a dedicated port (default: 993 for IMAP, 995 for POP3) and negotiate TLS
without prior clear-text protocol exchange.
Also, --ssl can be given on the command line, which switches all
configured server statements to this ssl mode.
Distributors are encouraged to review the NEWS file and move forward to
6.4.22, rather than backport individual security fixes, because doing so
routinely misses other fixes crucial to fetchmail's proper operation,
for which no security announcements are issued, or documentation,
or translation updates.
Fetchmail 6.4.X releases have been made with a focus on unchanged user and
program interfaces so as to avoid disruptions when upgrading from 6.3.Z or
6.4.X to 6.4.Y with Y > X. Care was taken to not change the interface
incompatibly.
A. Copyright, License and Non-Warranty
======================================
(C) Copyright 2021 by Matthias Andree, <matthias.andree@gmx.de>.
Some rights reserved.
© Copyright 2021 by Matthias Andree. This file is licensed under CC
BY-ND 4.0. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nd/4.0/
THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.
END of fetchmail-SA-2021-02
|
