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.
|Created:||April 21, 2004||Updated:||April 26, 2004|
|Description:||Solar Designer turned up a bug in the ext3 filesystem where blocks allocated to the journal file are not properly cleaned prior to use. This failure could expose some (random) kernel memory to an attacker, but only if that attacker can perform raw I/O to the device.|
|Created:||April 21, 2004||Updated:||December 22, 2004|
|Description:||The logcheck utility handles temporary files in an unsafe way, possibly allowing local attackers to overwrite files.|
|Created:||April 15, 2004||Updated:||May 7, 2004|
|Description:||Max Vozeler discovered two format string vulnerabilities in ssmtp, a simple mail transport agent. Untrusted values in the functions die() and log_event() were passed to printf-like functions as format strings. These vulnerabilities could potentially be exploited by a remote mail relay to gain the privileges of the ssmtp process (including potentially root).|
|Created:||April 19, 2004||Updated:||June 11, 2004|
|Description:||Steve Grubb discovered two potential issues in the utempter program:
|Created:||April 19, 2004||Updated:||November 15, 2005|
|Description:||XChat is vulnerable to a stack overflow that may allow a remote attacker to run arbitrary code. The SOCKS 5 proxy code in XChat is vulnerable to a remote exploit. Users would have to be using XChat through a SOCKS 5 server, enable SOCKS 5 traversal which is disabled by default and also connect to an attacker's custom proxy server. This vulnerability may allow an attacker to run arbitrary code within the context of the user ID of the XChat client.|
|Created:||April 15, 2004||Updated:||April 21, 2004|
|Description:||Steve Kemp discovered a vulnerability in xonix, a game, where an external program was invoked while retaining setgid privileges. A local attacker could exploit this vulnerability to gain gid "games".|
|Created:||April 21, 2004||Updated:||April 21, 2004|
|Description:||The ZCatalog component of the Zope application server can allow anonymous users and untrusted code to call arbitrary methods in the catalog indexes.|
ResourcesThe general concept, known as key escrow, key recovery, or trusted third-party encryption, hung around for a few years and was eventually forgotten. Who would have thought it would come back in the form of a luggage lock?"
Page editor: Jonathan Corbet
Next page: Kernel development>>
Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds