[15220] in bugtraq
Re: FW-1 IP Fragmentation Vulnerability
daemon@ATHENA.MIT.EDU (Chris Brenton)
Tue Jun 6 15:20:49 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <393CE014.81175D43@sover.net>
Date: Tue, 6 Jun 2000 07:27:16 -0400
Reply-To: cbrenton@sover.net
From: Chris Brenton <cbrenton@SOVER.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Lance Spitzner wrote:
>
> 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.
As a continuation, this may also effect other firewalls based on FW-1
code. If you are running a variant, check it to make sure you don't have
the same problem (one was not available for testing when Lance, Dameon &
myself where testing this).
You may also wish to check any other state based firewall for this
vulnerability to ensure that life is happy. I've also checked this
exploit against iptables (soon to be released replacement for ipchains)
version 1.1.0 and it passed with flying colors, even under 10x the load
that took out FW-1.
> 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
Lance did a great job of pointing out exactly what this fix does, but I
really wanted to stress it one more time. The fix shuts off all kernel
level reporting from FW-1. This is kind of nasty. Especially since this
completely blinds you to the above mentioned fragmentation attack as you
are shutting off the only logging that was taking place. If you do go
this route, please consider locating an IDS outside your firewall so you
can see this attack if it happens because you will be completely unable
to detect it at the firewall.
HTH,
Chris
--
**************************************
cbrenton@sover.net
* Mastering Cisco Routers
http://www.amazon.com/exec/obidos/ASIN/078212643X/
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/
