aboutsummaryrefslogtreecommitdiffstats
path: root/fetchmail-SA-2011-01.txt
blob: 267513110a1af598f7dc9eb16efd883b0101110d (plain)
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
pre { line-height: 125%; }
td.linenos .normal { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
span.linenos { color: inherit; background-color: transparent; padding-left: 5px; padding-right: 5px; }
td.linenos .special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
span.linenos.special { color: #000000; background-color: #ffffc0; padding-left: 5px; padding-right: 5px; }
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fetchmail-SA-2011-01: Denial of service possible in STARTTLS mode

Topics:		fetchmail denial of service in STARTTLS protocol phases

Author:		Matthias Andree
Version:	1.0
Announced:	2011-06-06
Type:		Unguarded blocking I/O can cause indefinite application hang
Impact:		Denial of service
Danger:		low
Acknowledgment:	Thomas Jarosch for sending detailed report

CVE Name:	CVE-2011-1947
CVSSv2:		(AV:N/AC:M/Au:S/C:N/I:N/A:C/E:U/RL:O/RC:C)
CVSS scores:	4.7: Base 6.3 (Impact 6.9 Exploitability 6.8) Temporal 4.7
		This is calculated without Environmental Score.
URL:		http://www.fetchmail.info/fetchmail-SA-2011-01.txt
Project URL:	http://www.fetchmail.info/

Affects:	fetchmail releases 5.9.9 up to and including 6.3.19

Not affected:	fetchmail release 6.3.20 and newer

Corrected in:	2011-05-26 Git, among others, see commit
		7dc67b8cf06f74aa57525279940e180c99701314

		2011-05-29 fetchmail 6.3.20-rc3 tarball (for testing)

		2011-06-06 fetchmail 6.3.20 release tarball


0. Release history
==================

2011-05-30 0.1	first draft (visible in Git and through oss-security)
2011-06-06 1.0	release


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 version 5.9.9 introduced STLS support for POP3, version
6.0.0 added STARTTLS for IMAP. However, the actual S(TART)TLS-initiated
in-band SSL/TLS negotiation was not guarded by a timeout.

Depending on the operating system defaults as to TCP stream keepalive
mode, fetchmail hangs in excess of one week after sending STARTTLS were
observed if the connection failed without notifying the operating
system, for instance, through network outages or hard server crashes.

A malicious server that does not respond, at the network level, after
acknowledging fetchmail's STARTTLS or STLS request, can hold fetchmail
in this protocol state, and thus render fetchmail unable to complete the
poll, or proceed to the next server, effecting a denial of service.

SSL-wrapped mode on dedicated ports was unaffected by this problem, so
can be used as a workaround.


3. Solution
===========

Install fetchmail 6.3.20 or newer.

The fetchmail source code is always available from
<http://developer.berlios.de/project/showfiles.php?group_id=1824>.

Distributors are encouraged to review the NEWS file and move forward to
6.3.20, 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.  Several such
(long-standing) bugs were fixed through recent releases, and an erratum
notice for SASL authentication was issued.

Fetchmail 6.3.X releases have always been made with a focus on unchanged
user and program interfaces so as to avoid disruptions when upgrading
from 6.3.X to 6.3.Y with Y > X.  Care was taken to not change the
interface incompatibly.


4. Workaround
=============

If supported by the server's configuration, fetchmail can be run in
ssl-wrapped rather than starttls mode. To that extent, the "ssl sslproto
ssl3" option must be configured (possibly replacing sslproto tls1 where
configured) to the rcfile, or "--ssl --sslproto ssl3" can be given on
the command line (where it applies to all poll configurations).

It is generally also advisable to enforce SSL certificate validation, by
either using --sslcertck on the command line, or using sslcertck in a
"default" configuration entry of the rcfile, or using sslcertck in
each of the relevant individual poll descriptions of the rcfile.


A. Copyright, License and Non-Warranty
======================================

(C) Copyright 2011 by Matthias Andree, <matthias.andree@gmx.de>.
Some rights reserved.

This work is licensed under the
Creative Commons Attribution-NoDerivs 3.0 Germany License (CC BY-ND 3.0).

To view a copy of this license, visit
http://creativecommons.org/licenses/by-nd/3.0/de/deed.en
or send a letter to:

Creative Commons
444 Castro Street
Suite 900
MOUNTAIN VIEW, CALIFORNIA 94041
USA


THIS WORK IS PROVIDED FREE OF CHARGE AND WITHOUT ANY WARRANTIES.
Use the information herein at your own risk.

END of fetchmail-SA-2011-01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk9/Yg4ACgkQvmGDOQUufZUICACg5GqwtyAFuOamJ3JtribzMe9U
k20AnRLlwx4HBC/Gk3AX1dWSrrQc8WYB
=GFzg
-----END PGP SIGNATURE-----
network with root privileges, use sscanf() to read remotely received data into fixed-length stack-based buffers without length limitation and so on. A full audit is required and security concepts will have to be applied. Random bits are:</p> <ul> <li>code talking to the network does not require root privileges and needs to run without root permissions</li> <li>all input must be validated, all strings must be length checked, all integers range checked</li> <li>all types will need to be reviewed whether they are signed or unsigned</li> </ul> <h2>SMTP forwarding</h2> <p>Fetchmail's multidrop and rewrite options will process addresses received from remote sites. Special care must be taken so these features cannot be abused to relay mail to foreign sites.</p> <p>ESR's attempt to make fetchmail use SMTP exclusively failed, fetchmail got LMTP and --mda options &ndash; the latter has a lot of flaws unfortunately, is inconsistent with the SMTP forwarder and needs to be reviewed and probably bugfixed. --mda doesn't properly work with multiple recipients, it cannot properly communicate errors and is best avoided for now.</p> <h2>Server-side vs. client-side state.</h2> <h3>Why we need client-side tracking</h3> <p>ESR asserted that server-side state were essential and those persons repsonsible for removing the LAST command from POP3 deserved to suffer. ESR is right in stating that the POP3 UID tracks which messages have been read <em>by this client</em> &ndash; and that is exactly what we need to do.</p> <p>If fetchmail is supposed to retrieve all mail from a mailbox reliably, without being disturbed by someone occasionally using another client on another host, or a webmailer, or similar, then <em>client</em>-side tracking of the state is indispensable. This is also needed to match behavior to ETRN and ODMR or to support read-only mailboxes in --keep mode.</p> <h3>Present and future</h3> <p>Fetchmail supports client-side state in POP3 if the UIDL option is used (which is strongly recommended). Similar effort needs to be made to track IMAP state by means of UIDVALIDITY and UID.</p> <p>This will also mean that the UID handling code be revised an perhaps use one file per account or per folder.</p> <h2>Concurrent queries/concurrent fetchmail instances</h2> <p>ESR refused to make fetchmail query multiple hosts or accounts concurrently, on the grounds that finer-grained locks would be hard to implement portably.</p> <p>The idea of using one file per folder or account to track UIDs on the client-side will make solving this locking problem easy &ndash; the lock can be placed on the UID file instead.</p> <h2>Multidrop issues</h2> <p>Fetchmail tries to guess recipients from headers that are not routing relevant, for instance, To:, Cc:, or Resent-headers (which are rare anyways). It is important that fetchmail insists on the real envelope operation for multidrop. This is detailed in <a href="http://home.pages.de/~mandree/mail/multidrop">my article &quot;Requisites for working multidrop mailboxes&quot;</a>.</p> <p>As Terry Lambert pointed out in the FreeBSD-arch mailing list on 2001-02-17 under the subject "UUCP must stay; fetchmail sucks", fetchmail performs DNS MX lookups to determine domains for which multidrop is valid, on the assumption that the receiving SMTP host upstream were the same as the IMAP or POP3 server.</p> <hr /> <table width="100%" cellpadding="0" summary="Canned page footer"> <tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td> <td width="30%" align="right">$Date$</td> </tr> </table> <br clear="left" /> <address>Matthias Andree <a href="mailto:matthias.andree@gmx.de">&lt;matthias.andree@gmx.de&gt;</a></address> </body> </html>