Vulnerability Note VU#464113

TCP/IP implementations handle unusual flag combinations inconsistently

To establish a TCP connection, a client and server must participate in a three-way handshake (as outlined in RFC793 - "Transmission Control Protocol"):

1. The client system sends a packet with the SYN flag set to the server.
2. The server acknowledges the client by sending a packet back with the SYN and ACK flags set.
3. The client completes the connection by sending a packet with the ACK flag set.

The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. The following diagram depicts the connection setup sequence:



A firewall inserted between a client and a server can be used to manage the connection setup and subsequent traffic flow between the two systems. In general, firewalls are of two types: packet-filtering firewalls, and application-level firewalls. Packet filters look at the source, destination, types, and options associated with the packet, while an application level firewall can "look inside" the packet to examine application-specific attributes. This document is concerned primarily with packet-filtering firewalls.

Section 3.4 (Establishing a connection) of RFC793 describes the three-way handshake as the standard procedure used to establish a connection. Firewalls will typically not allow this process between hosts that are not permitted to communicate with each other. For example, if an attacker sends a packet with the SYN bit set to a victim server, the firewall will not relay this packet to the victim because the firewall's rules only allow packets with the SYN bit set to come from certain hosts. As a result, the three-way handshake will not be completed, and the attacker will not be able to establish a connection with a host behind the firewall. This method of filtering SYN packets is typically the method used by packet-filtering firewalls to prevent certain hosts from "getting past the firewall."

How the Attacker Can Bypass the Firewall

An attacker is free to set whatever flags he chooses to set on any packet. RFC793 defines the meaning of most flag combinations, but it does not address all scenarios in which odd or unexpected flag combinations may be encountered. The method for handling the packet is largely left up to the TCP implementer, and each implementation handles flag combinations differently. For example, T/TCP (RFC1644) recognizes a packet with both the SYN and FIN flags set as being valid. Some implementations are even more liberal in what they accept and choose to treat any packet with the SYN flag set (regardless of what other flags are set or unset) as the opening in the three-way handshake. Other implementations are more conservative and drop packets with unexpected combinations of flags.

This ambiguity results in a vulnerability in certain situations. Suppose you have a firewall that passes packets if the RST flag is set, regardless of the state of the SYN flag. Furthermore, suppose you have a host that accepts a SYN flag as the opening of the three-way handshake even if the RST flag is set. An intruder can now send a packet with the SYN and RST flags set and establish a connection with the host behind the firewall in violation of the expected behavior.

A change introduced in the Linux Kernel (version 2.4.20) ensures that at least packets with both the SYN and RST flags set are discarded. This change was made within the function tcp_input.c.

Finally, research has indicated that multiple TCP implementations will allow a TCP session to be established with hosts by setting certain combinations of flags in an initial packet. The researchers go on to indicate that, "Other OSes than those tested above are expected to behave in a similar manner after obtaining such a discouraging result..."

Note that while the "detailed" research implies it is incorrect for a TCP implementation to accept a SYN with certain other bits set, it is actually a perfectly legal but rarely implemented behavior. Unfortunately, many firewalls either do not specify firewall rules that account for this (a documentation or user bug) or can not specify such firewall rules (an firewall implementation bug).

II. Impact

• create filtering rules designed to drop and/or reject packets with certain combinations of bits set in initial synchronization packets
• not use routable IP space except inside your DMZ
• if possible, switch to stateful filtering; however, you shouldn't do this unless you know your network traffic well enough to be sure that it has the required properties (symmetric routing, not too many flows, not too much idle time per flow)

http://hypermail.idiosynkrasia.net/linux-kernel/archived/2002/week46/1137.html
http://www.securityfocus.com/archive/1/296122/2002-10-19/2002-10-25/2
http://www.securityfocus.com/archive/1/296558/2002-10-19/2002-10-25/1
http://www.uwsg.iu.edu/hypermail/linux/kernel/0210.3/0365.html
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1644.html
http://www.packetfactory.net/projects/nemesis/
http://www.ibiblio.org/pub/docs/rfc/rfc793.txt
http://www.kb.cert.org/vuls/id/776781
http://www.kohala.com/start/ttcp.html

Credit

This issue was initially described by Paul Starzetz in a mail message sent to the Bugtraq mailing list. We also thank Florian Weimer, Avi Freedman, Alan Cox, and David Waitzman for their invaluable feedback on this subject.

This document was written by Ian A Finlay.

Other Information

If you have feedback, comments, or additional information about this vulnerability, please send us email.