Vulnerability Note VU#723308

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.

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.

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.

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.