TCP vulnerability: cancel red alert

There are several parameters which identify a particular TCP packet. The source and destination addresses are exactly that: who sent the packet, and who is to receive it. The destination port number allows the packet to be routed to the proper process on the receiving system; on the server side of a connection, the destination port will usually be a well-known number assigned to a specific service. For example, the process which receives electronic mail will be expecting it to arrive on port 25. The source port identifies the process which sent the packet. On the client (initiating) side of a connection, the source port is ostensibly a random number, though, in practice, they tend to be assigned in a sequential (and thus predictable) way. Yet another parameter is the sequence number, which describes where the packet fits within the overall stream. The initial sequence numbers for a connection are assigned randomly; they then increase as data is sent over the connection.

TCP packets also have a "flags" field for control purposes. One of those flags is called "reset" or "RST"; it indicates that the sending side is shutting down the connection immediately. Resets typically happen when one side receives a packet for a connection it knows nothing about. Suppose you log into a remote system with ssh, then go out for lunch; while you are eating, the remote system is rebooted. When you return and try to type over the connection, the remote system will have no record of it, so it will send back a reset packet. That's when you get that fun "connection reset by peer" message.

Suppose you were an Internet vandal looking to shut down other people's connections. This could be accomplished by sending the right sort of reset packet. Crafting this packet is not an entirely easy thing to do: you have to match all five of the parameters listed above. Presumably coming up with source and destination addresses would not be too hard, if you know which connection you are targeting. One of the two port numbers will probably be a well-known service number, and thus easily accessible. The other port number will require a guess, but the range of possible numbers is, in many cases, small. The hardest part is the sequence number; it is a randomly-chosen, 32-bit number. In the past, poor initial sequence number generation has allowed protocol attacks, but most of those problems are long since fixed. To mount a reset attack against a modern TCP implementation, the attacker must work through the entire space of 4 billion possible sequence numbers; by the time that has been accomplished, chances are the target connection will have shut down normally anyway.

Except, as it turns out, that is not entirely true. TCP uses a "receive window" to control the flow of data. The window gives a range of sequence numbers for which the destination is prepared to receive data; this window can vary widely between systems, but 32KB is a fairly common size. Since the two sides of a TCP connection may not share the exact same idea of what the current sequence number is (one side may have sent packets that the other has not received), a reset packet with a sequence number that falls anywhere inside the receive window will be honored. Thus an attacker need not try every possible sequence number; attempts may, instead, be spaced as widely as the probable receive window. That changes the situation significantly; if the other four parameters are correct, a usable sequence number can be found with less than 100,000 attempts. It does not take very long to send that many (very short) packets, even over a relatively slow connection.

So, a dedicated attacker stands a fairly good chance of shutting down a connection. What are the implications of this? Very few, for the most part. In general, the damage caused by a prematurely closed connection is small; the user swears and restarts their download operation. It would be hard to use this technique to shut down a web server; HTTP connections tend to be short-lived to begin with. That is why the largest threat is seen to be for applications which use long-lived TCP connections for some important task. The BGP protocol used for much of the core Internet routing is one such case; most of the affected systems have already been fixed, however.

For those who are in a situation where this sort of attack could pose a threat, there are a few things which can be done, including using IPSec, which is not vulnerable to this sort of problem, or configuring networking to use a smaller window size (but be aware that performance can be reduced). The IETF has also come up with a proposed protocol change which addresses the problem: when a reset packet is received which, while falling within the receive window, does not exactly match the sequence number, the receiving side will send an acknowledgment rather than immediately resetting the connection. That acknowledgment will contain the current sequence number as seen by the side receiving the reset, which will allow the sending of a second reset packet with the exact sequence number.

Some vendors (mostly router manufacturers) are issuing software updates to implement the IETF suggestion. Most of us, however, can sit back and look for something else to worry about.