User: Password:
Subscribe / Log in / New account


TCP vulnerability: cancel red alert

The mainstream press has been quick to proclaim a new vulnerability which threatens the entire Internet. CNN, for example, tells us: "Flaw could shut down Internet traffic". A bit of time spent actually understanding the problem will quickly make it clear, for most users, there is little to worry about.

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.

Comments (13 posted)

New vulnerabilities

kernel: ext3 information leak

Package(s):kernel CVE #(s):CAN-2004-0177
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.
Debian DSA-495-1 kernel-source-2.4.16 2004-04-26
Red Hat RHSA-2004:166-01 kernel 2004-04-21
Trustix TSLSA-2004-0020 kernel 2004-04-15

Comments (1 posted)

logcheck: symlink vulnerability

Package(s):logcheck CVE #(s):CAN-2004-0404
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.
Mandrake MDKSA-2004:155 logcheck 2004-12-22
Debian DSA-488-1 logcheck 2004-04-16

Comments (none posted)

ssmtp format string vulnerability

Package(s):ssmtp CVE #(s):CAN-2004-0156
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).
OpenPKG OpenPKG-SA-2004.020 ssmtp 2004-05-07
Gentoo 200404-18 ssmtp 2004-04-26
Debian DSA-485-1 ssmtp 2004-04-14

Comments (none posted)

utempter problems with symlink and strncpy

Package(s):utempter CVE #(s):CAN-2004-0233
Created:April 19, 2004 Updated:June 11, 2004
Description: Steve Grubb discovered two potential issues in the utempter program:
  1. If the path to the device contained /../ or /./ or //, the program was not exiting as it should. It would be possible to use something like /dev/../tmp/tty0, and then if /tmp/tty0 were deleted and symlinked to another important file, programs that have root privileges that do no further validation can then overwrite whatever the symlink pointed to.

  2. Several calls to strncpy without a manual termination of the string. This would most likely crash utempter.
Whitebox WBSA-2004:174-01 utempter 2004-06-10
Red Hat RHSA-2004:174-01 utempter 2004-05-26
Fedora-Legacy FLSA:1546 utempter 2004-05-18
Gentoo 200405-05 utempter 2004-05-13
Red Hat RHSA-2004:175-01 utempter 2004-04-30
Mandrake MDKSA-2004:031-1 utempter 2004-04-21
Fedora FEDORA-2004-108 utempter 2004-04-21
Slackware SSA:2004-110-01 utempter 2004-04-19
Mandrake MDKSA-2004:031 utempter 2004-04-19

Comments (none posted)

XChat 2.0.x SOCKS5 Vulnerability

Package(s):xchat CVE #(s):CAN-2004-0409
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.
Fedora-Legacy FLSA:123013 xchat 2005-11-14
Red Hat RHSA-2004:585-01 xchat 2004-10-27
Netwosix NW-2004-0014 xchat 2004-05-01
Red Hat RHSA-2004:177-01 X-Chat 2004-04-30
Mandrake MDKSA-2004:036 xchat 2004-04-21
Debian DSA-493-1 xchat 2004-04-21
Gentoo 200404-15 xchat 2004-04-19

Comments (none posted)

xonix fails to drop privileges

Package(s):xonix CVE #(s):CAN-2004-0157
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".
Debian DSA-484-1 xonix 2004-04-14

Comments (none posted)

zope: potential code execution

Package(s):zope CVE #(s):CVE-2002-0688
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.
Debian DSA-490-1 zope 2004-04-17

Comments (1 posted)


April CRYPTO-GRAM newsletter

Bruce Schneier's CRYPTO-GRAM newsletter for April is out; it looks at national ID cards, the risk of attacks on computerized voting machines, man-in-the-middle attacks, "BeepCard," Bluesnarfing, and TSA-approved locks. "The 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?"

Full Story (comments: 8)

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