Vulnerability Note VU#723308
TCP may keep its offered receive window closed indefinitely (RFC 1122)
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.
TCP implementations from multiple vendors are vulnerable to malicious or misbehaving connections that indefinitely advertize a zero receive window. RFC 1122 section 126.96.36.199 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 188.8.131.52 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.
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.
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.
|Vendor||Status||Date Notified||Date Updated|
|Check Point Software Technologies||Affected||26 Jun 2009||05 Nov 2009|
|Cisco Systems, Inc.||Affected||26 Jun 2009||18 Nov 2009|
|Extreme Networks||Affected||26 Jun 2009||14 Oct 2009|
|Force10 Networks, Inc.||Affected||26 Jun 2009||22 Jul 2011|
|Hewlett-Packard Company||Affected||26 Jun 2009||18 Nov 2009|
|Linux Kernel Archives||Affected||-||18 Nov 2009|
|Microsoft Corporation||Affected||26 Jun 2009||23 Nov 2009|
|Red Hat, Inc.||Affected||26 Jun 2009||01 Dec 2009|
|Sun Microsystems, Inc.||Affected||26 Jun 2009||05 Nov 2009|
|The SCO Group||Affected||26 Jun 2009||01 Dec 2009|
|NetApp||Not Affected||26 Jun 2009||14 Oct 2009|
|VMware||Not Affected||04 Sep 2009||14 Oct 2009|
|3com, Inc.||Unknown||26 Jun 2009||26 Jun 2009|
|ACCESS||Unknown||26 Jun 2009||26 Jun 2009|
|Alcatel-Lucent||Unknown||26 Jun 2009||26 Jun 2009|
CVSS Metrics (Learn More)
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.
- 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
If you have feedback, comments, or additional information about this vulnerability, please send us email.