Vulnerability Note VU#539363
State-based firewalls fail to effectively manage session table resource exhaustion
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.
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.
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
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:
Systems Affected (Learn More)
|Vendor||Status||Date Notified||Date Updated|
|Alcatel||Affected||05 Jun 2002||11 Oct 2002|
|Check Point||Affected||05 Jun 2002||31 Oct 2002|
|Cisco Systems Inc.||Affected||05 Jun 2002||31 Oct 2002|
|IBM||Affected||05 Jun 2002||23 Oct 2002|
|NetScreen||Affected||05 Jun 2002||27 Nov 2002|
|Apple Computer Inc.||Not Affected||05 Jun 2002||11 Oct 2002|
|Cray Inc.||Not Affected||05 Jun 2002||11 Oct 2002|
|Fujitsu||Not Affected||05 Jun 2002||11 Oct 2002|
|Microsoft Corporation||Not Affected||05 Jun 2002||15 Oct 2002|
|NetBSD||Not Affected||05 Jun 2002||11 Oct 2002|
|Nortel Networks||Not Affected||05 Jun 2002||27 Nov 2002|
|OpenBSD||Not Affected||05 Jun 2002||23 Oct 2002|
|3Com||Unknown||05 Jun 2002||11 Oct 2002|
|AT&T||Unknown||25 Sep 2002||11 Oct 2002|
|BSDI||Unknown||05 Jun 2002||11 Oct 2002|
CVSS Metrics (Learn More)
The CERT/CC thanks Stephen Gill for his discovery and analysis of this vulnerability.
This document was written by Jeffrey P. Lanza.
- 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.