firewall-1.fragment.txt

2000-06-07T00:00:00
ID PACKETSTORM:22063
Type packetstorm
Reporter Lance Spitzner
Modified 2000-06-07T00:00:00

Description

                                        
                                            `SCLAIMER>  
It was never my intent to identify a DoS attack on FW-1.  
I was attempting to research and understand how FW-1 handles  
IP Fragmentation. Everthing that follows is a result of  
that research. Full findings of my research can be found at  
http://www.enteract.com/~lspitz/fwtable.html.  
</DISCLAIMER>  
  
On Saturday, May 27, I identified a major DoS attack for FW-1.  
CheckPoint was immediately notified. Since then, they have  
developed a short term solution and are currently working  
on a long term solution (see details below).  
  
Symptopms  
---------  
CPU mysteriously hits 100% utilization, system locks up.  
Some systems may also crash, depending on OS type.  
  
  
Installations Vulnerable  
-------------------------  
1. I have reason to believe that every installation of FW-1 is  
vulnerable, regardless of Operating System type or version/patch  
level of the FW-1 installation. However, this has only been tested  
and confirmed with ver 4.1 SP1 on the Nokia, and ver 4.1 on NT and  
Solarix x86 platform.  
  
2. There is NO way to protect against it. Your rulebase  
cannot stop this attack. If your rulebase is denying everything,  
you are still vulnerable.  
  
3. FW-1 does NOT log these attacks in the firewall logs. Not  
only will the firewall will be taken out, but it is difficult to  
determine why. Illegally fragmented packets (such as those  
generated by jolt2) may be logged by Unix systems to  
/var/adm/messages.  
  
  
Exploit  
-------  
Most frag based attacks that use incomplete or illegal fragments  
will work, including jolt2. The firewall does not have to be  
attacked directly, if the frags are routed through the firewall  
for a system behind the firewall, FW-1 is still taken out.  
  
Reason  
------  
FW-1 does not inspect, nor does it log, fragmented packets untill the  
packet has first been completely reassembled. Since these exploit packets  
are never fully assembled, they are never inspected nor logged. Thus, the  
firewall's own rulebase cannot be used to protect against the attack.  
For more information on FW-1 IP Fragmentation reassembley, see  
http://www.enteract.com/~lspitz/fwtable.html  
  
The actual CPU utilization is most likely the result of the application  
attempting to reassemble hundreds or thousands of incomplete and  
illegally fragmented packets. As stated above, the firewall rulebase  
cannot block these packets, as they are never inspected.  
  
Other firewalls may have the same problem and vulnerability.  
  
Solutions  
---------  
1. CheckPoint has developed a short term solution to the problem. A  
percentage of CPU utilization is due to console error messages on  
some Unix systems. By disabling FW-1 kernel logging, some CPU  
utilization will be saved. However, all FW-1 kernel logging is  
disabled, you will have no capability for logging any firewall  
kernel events. At the command line on the Firewall, type as root:  
fw ctl debug -buf  
  
2. Ensure the operating system has the latest patches. Most operating  
system have recently released patches that help protect against fragment  
attacks.  
  
3. Run an IDS module (such as snort). When you detect frag attacks  
block the Src at the router (remember, the firewall CANNOT stop the  
attack, its rulebase is powerless). However, this method may not  
work with spoofed Src packets.  
  
4. CheckPoint is developing a long term solution, which will be  
distributed as part of a later Service Pack. However, this fix  
was not available for testing at the time of this post.  
  
Thanks  
------  
I appreciate the help and involvement from the following people  
in helping with this issue.  
  
Chris Brenton, Dartmouth's Institute for Security Technology Studies  
Dameon Welch-Abernathy, http://www.phoneboy.com/fw1  
  
Joe DiPietro, CheckPoint  
Robert Slayton, CheckPoint  
Mark Elliott, CheckPoint  
  
Lance Spitzner  
http://www.enteract.com/~lspitz/papers.html  
`