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 188.8.131.52 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 184.108.40.206 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.
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.
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.