Vulnerability Note VU#723308

TCP may keep its offered receive window closed indefinitely (RFC 1122)

Original Release date: 23 Nov 2009 | Last revised: 13 Feb 2013

Overview

Part of the Transmission Control Protocol (TCP) specification (RFC 1122) allows a receiver to advertise a zero byte window, instructing the sender to maintain the connection but not send additional TCP payload data. The sender should then probe the receiver to check if the receiver is ready to accept data. Narrow interpretation of this part of the specification can create a denial-of-service vulnerability. By advertising a zero receive window and acknowledging probes, a malicious receiver can cause a sender to consume resources (TCP state, buffers, and application memory), preventing the targeted service or system from handling legitimate connections.

Description

TCP implementations from multiple vendors are vulnerable to malicious or misbehaving connections that indefinitely advertize a zero receive window. RFC 1122 section 4.2.2.17 states that "A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open." The TCP connection is open however no data is being transmitted. This "stalled" state is generally referred to as the TCP persist condition.

The intent of RFC 1122 section 4.2.2.17 is that TCP must not terminate connections in the persist condition under normal operating conditions. It is possible to interpret the language narrowly to mean that TCP must not terminate connections in the persist condition under any circumstances, and this interpretation is likely to cause denial-of-services vulnerabilities. An attacker can asymmetrically consume server resources by making TCP connections, optionally requesting data, then setting the receive window to zero and repeatedly acknowledging window probes from the server.

General consensus of the IETF TCP Maintenance and Minor Extensions (TCPM) working group is that an operating system or application can abort TCP connections for any reason, including resource exhaustion. TCP itself cannot reliably decide to abort connections, and doing so would violate protocol standards, however there is no guidance against an operating system or application from aborting connections to recover memory resources.

This vulnerability, one specific attack (section 3), and a proposed defense (section 7) are further described in the individual IETF Internet-Draft "Clarification of sender behaviour in persist condition." A more comprehensive review of TCP state vulnerabilities is presented in CPNI Technical Note 3/2009: Security Assessment of the Transmission Control Protocol (TCP). The CPNI document describes the persist condition in section 3.7.2 and suggests countermeasures in section 7.1.2.

Persist condition attacks are implemented in the sockstress and Nkiller2 tools. Typically, these tools leverage a lightweight userland connection framework to generate many attacking connections without the overhead of full TCP state. There are different variants of attacks that exploit the persist condition, and some attack tools exploit other timers and states in TCP. Please see the CERT-FI Advisory on the Outpost24 TCP Issues for further information about sockstress including vendor responses.

The security aspects of the TCP persist condition has been discussed on the TCPM working group mailing list since at least 2006.

Impact

A remote, unauthenticated attacker can cause a denial of service. The attacker may be able to cause the operating system or network application to be unresponsive for the duration of the attack.

Solution

Modifications can be made to TCP implementations, interfaces, operating systems, and network applications, however any changes should consider the balance between improved resiliency and decreased interoperability. The IETF TCPM is considering the problem and any potential changes to TCP or guidance to implementors. As of the publication of this vulnerability note, the IETF has not yet decided whether additional clarifications of the TCP specifications are necessary. Some vendors have implemented changes to improve resiliency against zero window and other TCP state attacks. Consider the analysis and advice provided in the CPNI assessment.


Abort misbehaving TCP connections under resource exhaustion conditions

The consensus of the TCPM discussion seems to be that an operating system or application that faces resource exhaustion can selectively abort TCP connections that appear to be malicious (i.e., in persist condition and consuming relatively large amounts of memory). TCP must implement the persist behavior in RFC 1122, but a higher protocol layer can decide to abort a connection for any reason, including resource exhaustion. How and when to abort connections are open questions, and beyond the scope of the TCP protocol specification.

Section 7 of the "Clarification..." I-D describes an approach in which an application can limit how long the underlying TCP socket should tolerate connections in the persist condition. However, section 7.1.2 of the CPNI assessment warns that "...an attacker could simply open the window (i.e., advertise a TCP window larger than zero) from time to time to prevent this enforced limit from causing his malicious connections to be aborted."

A system that aborts TCP connections too aggressively is likely to drop legitimate connections. Carefully consider the likelihood of attack, the cost of dropping legitimate connections, and the benefit of dropping malicious connections before making design or configuration changes to TCP components of operating systems and applications. It is unlikely that one setting will work well for every TCP system.

Restrict Access

Restricting access or limiting connections to TCP services using firewalls can mitigate zero window attacks, at the cost of potentially blocking legitimate connections.

Systems Affected (Learn More)

Generally, any system or product that implements or uses TCP could be affected by this vulnerability, depending on how the product handles resource exhaustion and TCP connections in persist. By design, TCP does not inherently defend against denial-of-service attacks based on resource exhaustion. Decisions about how to detect and respond to such attacks are the responsibility of individual systems or products.

Please see the CERT-FI Advisory on the Outpost24 TCP Issues for further vendor information.

VendorStatusDate NotifiedDate Updated
Check Point Software TechnologiesAffected26 Jun 200905 Nov 2009
Cisco Systems, Inc.Affected26 Jun 200918 Nov 2009
Extreme NetworksAffected26 Jun 200914 Oct 2009
Force10 Networks, Inc.Affected26 Jun 200922 Jul 2011
Hewlett-Packard CompanyAffected26 Jun 200918 Nov 2009
Linux Kernel ArchivesAffected-18 Nov 2009
Microsoft CorporationAffected26 Jun 200923 Nov 2009
Red Hat, Inc.Affected26 Jun 200901 Dec 2009
Sun Microsystems, Inc.Affected26 Jun 200905 Nov 2009
The SCO GroupAffected26 Jun 200901 Dec 2009
NetAppNot Affected26 Jun 200914 Oct 2009
VMwareNot Affected04 Sep 200914 Oct 2009
3com, Inc.Unknown26 Jun 200926 Jun 2009
ACCESSUnknown26 Jun 200926 Jun 2009
Alcatel-LucentUnknown26 Jun 200926 Jun 2009
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base 0.0 AV:--/AC:--/Au:--/C:--/I:--/A:--
Temporal 0.0 E:ND/RL:ND/RC:ND
Environmental 0.0 CDP:ND/TD:ND/CR:ND/IR:ND/AR:ND

References

Credit

Thanks to Mahesh Jethanandani and CERT-FI for their efforts researching and coordinating vendor responses to this vulnerability. Thanks also to Barry Greene, Lars Eggert, Wesley Eddy, and David Borman for their review and comments.

This document was written by David Warren and Art Manion.

Other Information

  • CVE IDs: CVE-2009-1926 CVE-2008-4609
  • Date Public: 20 Jul 2006
  • Date First Published: 23 Nov 2009
  • Date Last Updated: 13 Feb 2013
  • Severity Metric: 15.59
  • Document Revision: 122

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.