aboutsummaryrefslogtreecommitdiffstats
path: root/fetchmail-SA-2007-01.txt
blob: 80958f80e6a1383da857059cc4b9cd249cab4dc5 (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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

fetchmail-SA-2007-01: APOP considered insecure

Topics:		APOP authentication insecure, fetchmail implementation lax

Author:		Matthias Andree
Version:	1.1
Announced:	2007-04-06
Type:		password theft when under MITM attack
Impact:		password disclosure possible
Danger:		low
Credits:	Gaƫtan Leurent
CVE Name:	CVE-2007-1558
URL:		http://fetchmail.berlios.de/fetchmail-SA-2007-01.txt
Project URL:	http://fetchmail.berlios.de/

Affects:	fetchmail release < 6.3.8

Not affected:	fetchmail release 6.3.8

Corrected:	2007-03-18 fetchmail SVN


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

2007-04-06 1.0	first release
2008-04-24 1.1	add --ssl to section 3. suggestion A below


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
=================================

The POP3 standard, currently RFC-1939, has specified an optional,
MD5-based authentication scheme called "APOP".

APOP should no longer be considered secure.

Additionally, fetchmail's POP3 client implementation has been validating
the APOP challenge too lightly and accepted random garbage as a POP3
server's APOP challenge, rather than insisting that the APOP challenge
conformed to RFC-822, as required by RFC-1939.

This made it easier than necessary for man-in-the-middle attackers to
retrieve by several probing and guessing the first three characters of
the APOP secret, bringing brute forcing the remaining characters well
within reach.


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

Either of these is currently considered sufficient.

A. Only use APOP on SSL or TLS secured connections with mandatory and thorough
   certificate validation, such as fetchmail --sslproto tls1 --sslcertck
   or --ssl --sslproto ssl3 --sslcertck), or equivalent in the run control file.

B. Avoid APOP and use stronger authenticators.

C. If you must continue to use APOP without SSL/TLS, then install
   fetchmail 6.3.8 or newer, as it is less susceptible to the attack by
   validating the APOP challenge more strictly to make the attack
   harder. The fetchmail 6.3.8 source code is available from
   <http://developer.berlios.de/project/showfiles.php?group_id=1824>.


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

(C) Copyright 2007, 2008 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-2007-01.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFIV7WXvmGDOQUufZURAg8MAKDewyOyTpRs6HMcNLMA0vXx4glwLQCeOov6
r9AYJJu51+yAhjox79Tli+I=
=pGe2
-----END PGP SIGNATURE-----