search menu icon-carat-right cmu-wordmark
Carnegie Mellon University

Software Engineering Institute

CERT Coordination Center

TCP/IP implementations handle unusual flag combinations inconsistently

Vulnerability Note VU#464113

Original Release Date: 2003-03-20 | Last Revised: 2012-02-03

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)

Vendor Information

464113
 
Expand all

View all 70 vendors View less vendors


CVSS Metrics

Group Score Vector
Base
Temporal
Environmental

References

Acknowledgements

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
Severity Metric: 32.25
Date Public: 2002-10-18
Date First Published: 2003-03-20
Date Last Updated: 2012-02-03 18:46 UTC
Document Revision: 91

Sponsored by CISA.

Download PGP Key

Read CERT/CC Blog

Learn about Vulnerability Analysis