Vulnerability Note VU#464113

TCP/IP implementations handle unusual flag combinations inconsistently

Original Release date: 20 Mar 2003 | Last revised: 03 Feb 2012

Overview

Various vendors' TCP/IP implementations handle packets containing unusual flag combinations in different ways, which may lead to a violation of implicit or explicit security policies.

Description

Background on TCP/IP Connection Semantics

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).

Impact

The impact of this vulnerability is that an attacker may be able to establish connections with hosts behind firewalls in violation of implied security policies. As a result, an attacker can send data to hosts and services that he ordinarily cannot reach. An intruder could also leverage this flaw to exploit a vulnerability in passive software listening promiscuously on the inside of the firewall (e.g., vulnerability in tcpdump or some similar vulnerability). Note that the specific kinds of packets that may bypass a firewall are highly dependent on the implementation of the firewall.

Solution

Apply a vendor patch. If a vendor patch is not available for your TCP implementation (and even if one is), you may wish to:

  • 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)

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
The SCO Group (SCO Linux)Affected23 Oct 200201 May 2003
Apple Computer, Inc.Not Affected23 Oct 200228 Oct 2002
Check PointNot Affected23 Oct 200225 Oct 2002
ClavisterNot Affected-01 Apr 2003
Cray Inc.Not Affected23 Oct 200230 Oct 2002
Finjan SoftwareNot Affected-25 Oct 2002
Foundry Networks Inc.Not Affected-01 Apr 2003
FujitsuNot Affected23 Oct 200203 Dec 2002
Funk SoftwareNot Affected-25 Oct 2002
Hewlett-Packard CompanyNot Affected23 Oct 200210 May 2005
IBM CorporationNot Affected23 Oct 200201 Apr 2003
Ingrian Networks, Inc.Not Affected-18 Mar 2003
Lotus SoftwareNot Affected23 Oct 200214 Mar 2003
Microsoft CorporationNot Affected23 Oct 200229 Oct 2002
NetScreenNot Affected-14 Mar 2003
If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A N/A

References

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

  • CVE IDs: CVE-2002-2438
  • Date Public: 18 Oct 2002
  • Date First Published: 20 Mar 2003
  • Date Last Updated: 03 Feb 2012
  • Severity Metric: 32.25
  • Document Revision: 91

Feedback

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