Hello All,
There has been much discussion regarding a recently announced vulnerability
in the CheckPoint firewall product. This announcement was accompanied by a
workaround suggested by CheckPoint. For those of you who have not read the
initial finding and the response from CheckPoint, you may read them here:
http://msgs.securepoint.com/cgi-bin/get/fw1-0006/248.html
http://msgs.securepoint.com/cgi-bin/get/fw1-0006/211.html
The data provided above did not seem to provide a clear picture of the
root cause or all of the symptoms. What was missing from the discussions
above
was a comparison between a box enduring a steady stream of fragmented and
duplicate UDP packets and a box enduring the same rate of properly formed
UDP packets.
Methodology:
In an effort to fully understand the root cause, a private team of
individuals undertook a series of tests to validate and elucidate the
previous findings. Several platforms were tested with several iterations
of code. The platforms tested were:
Solaris 2.7 (aka Solaris 7, SunOS 5.7)
AIX 4.3.3
IPSO 3.2.1 (Nokia OS)
HP-UX 10.20
The CheckPoint code tested was, in all cases, version 4.0. The code used
for the tests is detailed below. While the original jolt2.c and rc8.c code
was
used, several permutations were created to fully test the theories.
jolt2.c - Code that creates fragmented UDP and ICMP duplicate packets.
rc8.c - Modified rc8.c code which generates a steady stream of valid
(e.g.non-fragmented, unique) UDP packets.
eviljolt.c - jolt2.c without fragments or duplicates, and with the UDP
header set improperly.
incjolt.c - jolt2.c that does not create fragmented or duplicate packets.
newjolt.c - jolt2.c that does not create fragmented packets.
decaf.c - jolt2.c with a sleep(1) (approximately one second pause) between
each packet.
The rc8.c tool functions much like the incjolt.c tool. However, it was
important to prove that the effect from any such tool would be the same,
and to baseline jolt2.c against a "competitor." The methodology was crafted
to
obtain both a baseline (the control group) as well as various measurements
of different platforms and situations.
1. Run all code through a host with CheckPoint FW-1 running.
2. Run all code through a host with CheckPoint FW-1 running and logging
effectively disabled.
3. Run all code through a host with CheckPoint FW-1 not running.
A spreadsheet with the test results is included below.
Conclusions and Recommendations:
The data is quite clear; the issue is NOT IP fragmentation. Further,
disabling logging as a workaround has dubious technical merit and may
actually provide more harm than good.
There exist two real issues.
1. Load.
The jolt2.c code and its kin are capable of generating a steady and intense
stream of packets. Regardless of the rule base, each packet must be handled
by CheckPoint, and this causes undue stress on the host. The effect to the
CPU
happens regardless of the packet type or deformity, e.g. fragmentation,
incorrect
header size, or even properly formed packets. It should be noted that this
load
causes high CPU utilization (upwards of 100%) even on hosts that are NOT
running CheckPoint, resulting in packet loss in some cases. However,
where packet loss does not occur, a high CPU utilization percentage is not
considered harmful. High CPU utilization may effect latency, however, and
this
was not tested.
2. Logging.
While it is the case that the logging, by CheckPoint, of the incorrectly
fragmented packets does increase the CPU load and the percentage of
dropped packets on the Sun and Nokia platforms, there exist other problems
which also generate copious error messages. For example, setting the UDP
header size to an incorrect value produces a different set of copious error
messages on a firewall performing NAT. However, while sending the
errors to a bucket in memory with fw ctl debug -buf does decrease CPU
utilization and the percentage of dropped packets on the Sun and Nokia
platform, the firewall continues to suffer up to 65% packet loss during the
attack. Therefore, without logging, the administrator will be unable to
determine the cause of the high packet loss, high CPU utilization, and
attack
type.
There are two error messages that can result in higher CPU utilization and
packet loss. These are:
1. FW-1: packet size too big (65529) from 0x<HEX ADDRESS of SOURCE>, ip_p=17
This message comes as a result of a bogus fragmentation attack such as
jolt2.c.
2. FW-1: fw_xlate_backw_drv: problem getting conn (46 22 17)
This message comes as a result of a corrupted UDP header attack such as
eviljolt.c.
Note that eviljolt.c was created during the testing, and has not been
released "in the wild." However, code that performs a similar function is
likely to exist. Certain platforms issued no error messages at all while
enduring a jolt2.c attack, e.g. HP-UX and AIX, and therefore derived no
benefit from the fw ctl debug -buf workaround. The AIX and HP-UX platforms
suffered very little from the jolt2.c attack. In the case of a jolt2.c
attack, therefore, certain platforms are likely to remain completely
unaffected.
Clearly, the platform on which CheckPoint runs makes a significant
statistical difference regardless of the permutation of the jolt2.c code
utilized. The reactions to such attacks are as unique as the platforms
themselves. The recommendation is that this supposed vulnerability be
treated as nothing more than what it is -- a potential load-based DoS
attack.
With proper configuration of the border routers (e.g. CAR or ACLs for
UDP and ICMP), this attack is less dangerous than most DoS
TCP-based attacks many often endure.
It would be wise to configure the border routers to mitigate the bandwidth
utilization by UDP and ICMP, and leave console logging enabled on the
CheckPoint firewalls so that an attack can be properly detected, analyzed,
and blocked. The CPU utilization on the firewalls should also be closely
monitored.
The above tests were conducted by:
Stephen Gill, [EMAIL PROTECTED]
Brian Fernald, [EMAIL PROTECTED]
Rob Thomas, [EMAIL PROTECTED]
frag testing.zip
