The APOP protocol allows remote attackers to guess the first 3 characters of a password via man-in-the-middle (MITM) attacks that use crafted message IDs and MD5 collisions.
From fetchmail-6.3.8's changelog: fetchmail 6.3.8 (released 2007-04-06): # SECURITY STRENGTHENING: * Make the APOP challenge parser more distrustful and have it reject challenges that do not conform to RFC-822 msg-id format, in the hope to make mounting man-in-the-middle attacks (MITM) against APOP a bit more difficult. (CVE-2007-1558, reported by Gaëtan Leurent, published 2007-04-02 on Bugtraq) APOP is claimed insecure by Gaëtan Leurent for MITM scenarios for typical setups: based on MD5 collisions, it is purportedly possible to recover the first three characters of the shared secret (password), which would then make recovery of the shared secret a matter of hours or minutes; this would then enable the attacker to impersonate the client vis-à-vis the server. For further details, check * Gaëtan Leurent, "Message Freedom in MD4 and MD5 Collisions: Application to APOP", Fast Software Encryption 2007, Luxembourg. (Proceedings to appear in Springer's Lecture Notes on Computer Science.) * The mailing list discussion thread at <http://lists.berlios.de/pipermail/fetchmail-devel/2007-March/000887.html>
Um, I forgot to mention that 6.3.8 has been in the tree for quite some time now...
Thx Ticho. Arches please test and mark stable. Target keywords are: fetchmail-6.3.8.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86 ~x86-fbsd"
ia64 + x86 stable
sparc stable.
amd64 stable
ppc64 stable
Stable for HPPA.
Alpha done.
ppc stable, ready for GLSA voting
voting NO. 3 chars != full password, if someone uses a 3 chars password he has more serious problems to worry about :)
Voting NO and closing. Feel free to reopen if you disagree.
mips stable.