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] __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
