TCP Window Attacks

TCP Window Attacks

A particularly nasty attack that is allowed by the TCP RFCs is an intentional variant on the silly window syndrome. A TCP connection uses a window size advertisement in ACK packets to help the server send data no faster than the client can receive it. If the client's buffers are completely full, it can even send the server a window size of zero, which causes the server to wait to send more data. For a much more thorough description, see Internetworking with TCP/IP Vol. 1: Principles, Protocols, and Architectures (4th Edition) by Douglas Comer (Prentice Hall, 2000).

The way the attack works is that a malicious client will create a connection, set the window size to a very small number (or zero), and cause the server to send the data very slowly and with very high overhead. For every few bytes of data, there's around 40 bytes worth of TCP and IP headers. Depending on how you've written your server application, it could cause you to start blocking when trying to send data, which consumes your worker threads. This typically hasn't been something we've worried about in the past our TCP/IP stacks negotiate this for us, and there's very little ability to adjust how this works in terms of normal socket calls. Unfortunately, some people have written specialized apps to cause everyone trouble.

The defense is to always check returns on send calls. This is good practice in general; I've seen connections get closed between the initial connect and the first send. It's also possible under ordinary conditions for a server to need to transmit data slowly. Consider a fast Web server on a gigabit link transmitting to a system on a modem link. If a client takes an inordinate amount of time to process what you've been sending them, it might be best to do an abortive close and shutdown of the socket.