From upstream advisory at $URL:
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.
Install fetchmail 6.3.20 or newer after it will have become available.
(Note that the announcements may be publicly visible quite some time
before the release is made, particularly for minor bugs.)
fetchmail 6.3.20 has been released.
Thank you Tim. In the tree:
+*fetchmail-6.3.20 (07 Jun 2011)
+ 07 Jun 2011; Eray Aslan <email@example.com> +fetchmail-6.3.20.ebuild:
+ Version bump - security bug #369403
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Am limited by not running and ISP amil account now. only the browser driven hotmail. therefore can't start the fetchmail daemon.
However, emerged ok, the conf script brought up the gui to configure fetchmail. Passed test phase, looks ok.
Stable for HPPA.
amd64 done. Thanks Ian
Thanks, everyone. GLSA Vote: no.
fetchmail 5.9.9 through 6.3.19 does not properly limit the wait time after
issuing a (1) STARTTLS or (2) STLS request, which allows remote servers to
cause a denial of service (application hang) by acknowledging the request
but not sending additional packets.
no too, and closing.