I have identified a denial of service attack

that can be launched against Firewall-1 that has

identical results to the IP fragmentation attack

identified by Lance Spitzner.



Symptoms: Firewall CPU hits 100% utilization, console

locks up, a reboot only temporarily solves the problem.



Vulnerable: All versions of Firewall-1 4.1 on Solaris 2.x

using a limited-IP license



Probably Vulnerable: All versions of Firewall-1 4.1 using

a limited-IP license on Nokia IPSO, possibly other

variants of Unix



Not vulnerable: Firewall-1 4.0 (all service packs) and

earlier



Discussion:



On firewall modules with a limited-IP license, Firewall-1

counts the number of unique source IP addresses entering

all non-outside interfaces.  The outside interface typically

is Internet-facing.  If more IP addresses are counted

that the firewall module is licensed for, a warning

message is output to the firewall's console.  In 4.1, the warning

includes a list of all IP addresses counted in the Firewall-1

licensing calculation.  The 4.0 message only included the number of

IP addresses corresponding to the licensed limit.



By sending a large number of packets with spoofed source

addresses to any inside interface, enough addresses will be

included in the console output to cause a new warning

message to be issued before the previous one can finish.

As a result the console device will be overrun and begin

to consume large amounts of CPU time.  This output

makes the console virtually unusable making it more difficult

to recover from this situation.



There is no way to block this behavior in the rule base.  Even

if the spoofed packets in question are dropped explicitly by

a rule or implicitly by antipspoofing they will still be

included in the license calculation.  A reboot will not clear

this problem either, since Firewall-1 will begin sending

the license violation messages to the console immediately upon

rebooting.  Clearing the license count as described at PhoneBoy's

site will help temporarily, but if the flood of spoofed packets

continues Firewall-1 will rapidly end up in the same state

again.



Reproducing the Vulnerability:



To reproduce this vulnerability these two conditions must both be

true:



1) The firewall module has to have a limited-IP license

2) An attacker has to be able to route packets to any

   inside interface of the firewall.  Note that this

   could include DMZ interfaces as well as the "inside"

   network; only the single defined outside interface is

   impervious.  Also note that the packets do not

   have to be accepted by the firewall's security policy.



Any tool that can send a stream of packets with random, unique

source IP addresses can be used to reproduce this problem.

The SYN flooder synk4.c is an excellent example.  In our

testing we found that once the firewall module was attempting

to output approximately 6,000 IP addresses to the console

it would be overrun.  On a high-speed LAN a SYN flooder

could send this amount of traffic in seconds.



Work Around/Fix:



Similar to the IP Frag attack, issuing a 'fw ctl debug -buf'

will prevent this console logging from consuming excessive CPU.

While many firewall administrators installed this workaround

earlier to combat the frag problem, it was probably removed

from the fwstart script when they upgraded to SP2 or later.



Vendor Reporting:



I contacted CheckPoint immediately after discovering this

problem.  They have confirmed that it is indeed a problem and

recommend using the 'fw ctl debug -buf' workaround as

an immediate solution.  CheckPoint is currently researching

a more permanent solution to the problem and will include

the solution in a further release.



Initial Discovery:



I was called into a client site whose High Availability

Firewall cluster was hanging and crashing constantly.

A closer examination of the firewalls

revealed that they were 100% utilized spewing

license warnings onto the console port which

was overwhelmed with data.  A "fw lichosts"

revealed thousands of bogus addresses being

counted in the license calculation and thus

pushing the customer over their license.

These bogus addresses were things like

254.3.4.5, 0.0.3.4 and so on; the external

interface was defined properly so that

wasn't the problem.



It turned out that a Cisco LocalDirector

was spewing packets with garbage source and

destination IP addresses on a DMZ interface.

This is a known Cisco bug and has Cisco bugID

#CSCdr08284.  Then it occurred to me than one could

induce this situation by flooding the firewall with

IP datagrams carrying random source IP addresses.

Firewall-1 would be so busy spewing license

warnings to the console nothing else would get done.



References:



Lance Spitzner's original bugtraq post concerning the IP frag attack:



http://www.securityfocus.com/archive/1/63478



CheckPoint's official page concerning the previous IP frag attack:



http://www.checkpoint.com/techsupport/alerts/ipfrag_dos.html



PhoneBoy's Firewall-1 FAQ site:



http://www.phoneboy.com/fw1



Thanks:



I'd like to thank Scott Walker Register of CheckPoint for his

prompt and courteous assistance in dealing with this matter.



I'd also like to thank Geoff Hannam  for

his assistance in isolating this problem.



Tim Hall

Senior Security Engineer

The Root Group

thall@rootgroup.com

http://www.rootgroup.com