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.

This update fixes CVE-2011-1947.

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

New fetchmail packages are available for Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, 12.0, 12.1, 12.2, 13.0, 13.1, 13.37, and
-current to fix a security issue.

Multiple vulnerabilities were discovered and corrected in fetchmail :

fetchmail 4.6.3 through 6.3.16, when debug mode is enabled, does not properly handle invalid characters in a multi-character locale, which allows remote attackers to cause a denial of service (memory consumption and application crash) via a crafted (1) message header or (2) POP3 UIDL list (CVE-2010-1167). NOTE: This vulnerability did not affect Mandriva Linux 2010.2.

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 (CVE-2011-1947).

Packages for 2009.0 are provided as of the Extended Maintenance Program. Please visit this link to learn more:
http://store.mandriva.com/product_info.php?cPath=149 products_id=490

The updated packages have been upgraded to the 6.3.20 version which is not vulnerable to these issues.

Matthias Andree reports :

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.

ID	Name	Product	Family	Severity
55393	Fedora 13 : fetchmail-6.3.20-1.fc13 (2011-8059)	Nessus	Fedora Local Security Checks	medium
55390	Fedora 14 : fetchmail-6.3.20-1.fc14 (2011-8021)	Nessus	Fedora Local Security Checks	medium
55389	Fedora 15 : fetchmail-6.3.20-1.fc15 (2011-8011)	Nessus	Fedora Local Security Checks	medium
55173	Slackware 10.0 / 10.1 / 10.2 / 11.0 / 12.0 / 12.1 / 12.2 / 13.0 / 13.1 / 13.37 / 8.1 / 9.0 / 9.1 / current : fetchmail (SSA:2011-171-01)	Nessus	Slackware Local Security Checks	medium
54991	Mandriva Linux Security Advisory : fetchmail (MDVSA-2011:107)	Nessus	Mandriva Local Security Checks	medium
54983	FreeBSD : fetchmail -- STARTTLS denial of service (f7d838f2-9039-11e0-a051-080027ef73ec)	Nessus	FreeBSD Local Security Checks	medium

Detections

Analytics

CVE-2011-1947

high

Tenable Plugins

medium

medium

medium

medium

medium

medium