Date: Wed, 17 Jan 2001 22:50:55 -0700
From: Tim Hall <thall@ROOTGROUP.COM.>
To: [email protected]Subject: Licensing Firewall-1 DoS Attack
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 <geoffh@nrfg.com.> for
his assistance in isolating this problem.
Tim Hall
Senior Security Engineer
The Root Group
[email protected]
http://www.rootgroup.com
