Vulnerability Note VU#539363

State-based firewalls fail to effectively manage session table resource exhaustion

Original Release date: 15 Oct 2002 | Last revised: 06 Jan 2003


There is a vulnerability in several state-based firewall products that allows arbitrary remote attackers to conduct denial of service attacks against vulnerable firewalls.


Many firewall products use state tables to determine whether a given packet belongs to an existing session between two hosts on opposite sides of the firewall. When the firewall encounters packets that match its rulebase but do not match a currently defined state, a state table entry is added to track the new session. The firewall can remove entries from the state table for several reasons, including expiration of session time-out values and detection of connection teardown packets (such as TCP FIN or TCP RST).

If new entries are added to the state table more rapidly than the firewall is permitted to remove them, the table will eventually fill to capacity. When this occurs, many firewall implementations will refuse to accept incoming packets that do not match an existing session state. In these implementations, no new connections can be established across the firewall, resulting in a denial of service condition. It is important to note that in some firewall implementations, an attacker can fill the session state table with relatively small amounts of traffic, significantly less than the bandwidth capabilities of the firewall's network interface.

There are several methods that attackers can use to exploit this vulnerability:


To establish a TCP connection, the client and server must participate in a three-way handshake. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. 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. Here is a view of this message flow:

Diagram of TCP 3-Way Handshake

In a SYN Flood attack, the attacker sends SYN packets with forged IP source addresses such that the incoming traffic appears to originate from multiple clients. Assuming that the packets match the firewall's rulebase, it will create state table entries to track the pending connections. Because the client addresses are forged, the SYN-ACK messages sent to the clients by the server will be discarded, leaving the firewall's state table filled with bogus entries and eventually creating a denial-of-service condition.

UDP Flood

In a UDP Flood attack, the attacker sends large numbers of small UDP packets with forged IP source addresses. However, because the UDP protocol is connectionless, there are no session status indicators (SYN, SYN-ACK, ACK, FIN, or RST) to assist the firewall in detecting the abnormal protocol states that indicate an attack. As a result, state-based firewalls must rely upon source and destination addresses to create state table entries and set session timeout values.

Crikey CRC Flood

Stephen Gill has discovered a new method of attacking state-based firewalls that he has dubbed the Crikey CRC Flood (C2 Flood). CRC checksums are computed at each network layer (Data Link, Transport, and Network) and are used to detect data corruption caused by transmission errors. A C2 Flood is comprised of packets containing invalid checksums for Transport Layer protocols such as UDP and TCP. Because examination of Transport Layer data is not necessary for firewall operations, many implementers choose to optimize performance by ignoring these checksums. Therefore, if an incoming C2 Flood packet matches the firewall's rulebase, it will create a session table entry and pass the invalid packet to the destination host.

Unlike the firewall, the destination host must verify all checksums to prevent itself from accepting corrupted packets. In accordance with common networking convention, most hosts that receive invalid packets from a C2 Flood will simply discard them, assuming that failure to respond will cause the source host to retransmit the data. This presents a problem for the firewall because, under these conditions, the destination host will not provide feedback that the firewall can use to adjust its state table.


Arbitrary remote attackers can conduct denial of service attacks against vulnerable firewalls.


Follow the recommendations of your vendor

Please see the vendor information section of this document for a list of vendor-specific recommendations for addressing this vulnerability.

The attacks described in this document are difficult to block completely, but there are several improvements that developers can make to reduce their impacts. Several of these techniques are described below:

Use firewall features that detect and block flood traffic

Many firewalls provide features that can detect and block UDP and TCP SYN floods. The CERT/CC recommends that site administrators make use of these features whenever possible.

Use dynamically resizeable state tables

State tables that use dynamically allocated storage can expand to accommodate large numbers of states. This will increase the difficulty of exploiting this vulnerability, but it is important to note that the size of a dynamic state table will still be bounded by a firewall's available memory.

Use separate timeout values for initial sessions

Maintaining separate session timers for initial and established sessions allows state table entries generated by attack traffic to be rapidly removed while still permitting legitimate entries to remain in the state table. Since most attacks rely upon forged IP source addresses from which no reply is expected, attack traffic is unlikely to create state table entries that appear to be established sessions.

Use dynamically adjustable session timers (Aggressive Aging)

As the session time out value decreases, the attacker must increase the traffic rate to ensure that new entries are created faster than the firewall is permitted to remove them. By using dynamic session timers that decrease in response to state table congestion, the firewall can increase its rate of session expiration, making this vulnerability more difficult to exploit.

Allow connection tracking to be disabled

The ability to disable connection tracking for certain protocols would provide administrators with increased flexibility in defending against the attacks described above.

Systems Affected (Learn More)

VendorStatusDate NotifiedDate Updated
AlcatelAffected05 Jun 200211 Oct 2002
Check PointAffected05 Jun 200231 Oct 2002
Cisco Systems Inc.Affected05 Jun 200231 Oct 2002
IBMAffected05 Jun 200223 Oct 2002
NetScreenAffected05 Jun 200227 Nov 2002
Apple Computer Inc.Not Affected05 Jun 200211 Oct 2002
Cray Inc.Not Affected05 Jun 200211 Oct 2002
FujitsuNot Affected05 Jun 200211 Oct 2002
Microsoft CorporationNot Affected05 Jun 200215 Oct 2002
NetBSDNot Affected05 Jun 200211 Oct 2002
Nortel NetworksNot Affected05 Jun 200227 Nov 2002
OpenBSDNot Affected05 Jun 200223 Oct 2002
3ComUnknown05 Jun 200211 Oct 2002
AT&TUnknown25 Sep 200211 Oct 2002
BSDIUnknown05 Jun 200211 Oct 2002
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



The CERT/CC thanks Stephen Gill for his discovery and analysis of this vulnerability.

This document was written by Jeffrey P. Lanza.

Other Information

  • CVE IDs: Unknown
  • Date Public: 15 Oct 2002
  • Date First Published: 15 Oct 2002
  • Date Last Updated: 06 Jan 2003
  • Severity Metric: 19.69
  • Document Revision: 120


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