Overview
There is a vulnerability in several state-based firewall products that allows arbitrary remote attackers to conduct denial of service attacks against vulnerable firewalls.
Description
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. 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. |
Impact
Arbitrary remote attackers can conduct denial of service attacks against vulnerable firewalls. |
Solution
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:
|
Vendor Information
CVSS Metrics
| Group | Score | Vector |
|---|---|---|
| Base | ||
| Temporal | ||
| Environmental |
References
Acknowledgements
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: | None |
| Severity Metric: | 19.69 |
| Date Public: | 2002-10-15 |
| Date First Published: | 2002-10-15 |
| Date Last Updated: | 2003-01-06 21:50 UTC |
| Document Revision: | 120 |