Firewall-1 information

I've just been in contact with Arjan Vos who originally reported what seemed to be a problem with the Firewall-1 package from Checkpoint. There is not a security flaw in firewall-1 itself. The problem appears to be with the complex interations between the operating system and the firewall. Following is a series of messages which were posted to the Firewalls mailing list, only the first of which was relayed on to Best-Of-Security, which some people forwarded on to me, and caused all the panic. Once again, apologies to everyone out there that was puzzled by this.

You may want to check out Checkpoints thoughts on preventing the dreaded Ping of Death. 

Hi all,

In testing a Soltice's firewall-1 (release 2) I found the following:

The firewall's filter rules block all inbound traffic, inculding ICMP 
packets. However, when pinging the firewall with ping -l 70000, 
firewall-1's GUI somehow seemed to crash as well as all the filter rules.

At the same time with pinging I was able to telnet to the firewall and 
thus bypass the filter rules (which seem to be crashed with the GUI). 
After several minutes the GUI came back to life as well as the filter 
rules, but it was to late by then!!!

More tests seem to reveal there's a problem with the logging facilities
of FW-1. It was so busy logging the ping, it "forgot" to do anything
else.....:-))

Can somebody help me out on this one? Has anybody encoutered the same
thing happening? Is it a problem with FW-1's use of syslog or is it a bug???

Thanks in advance,

Arjan Vos
KPMG EDP Auditors
avos@kpmg.nl

--------------- inserted message 11/11/96------------------

Thanks for the many responses on my first message,

I've been delving into this strange problem last weekend, but am still a bit
clueless.

The machine on which Firewall-1 is installed is a Sun Sparc-4 with Solaris
2.4. For administration the GUI fwgui is being used. The machine from which
the tests are performed is a Pentium with Linux 2.0.19 kernel. It is connected
to external's and internal's interface by means of a hub, but a direct
cross-cable also worked. For telnetting to the firewall while it was being
pinged, I used a tool called NetCat. With NetCat one is able to generate TCP
streams manually to whatever port... in this case the telnet-port, because
that one is open (actually WAS open, we have disabled it now).

First the test is performed on the external interface and the fwgui and filter
rules go down. This same goes for the test on the internal interface. When
testing over the Internet (28k8 modem) Firewall-1 holds up just fine, so it
must be something with speed. I found out that with high speeds, the syslog
won't hold up. What happens is that the syslog writes are being interrupted
and restarted. This goes on and on and seem to trigger some catch-22 situation
during which other system calls regarding filter processing are put in hold
and after finishing the receipt of the ICMP packets the other system calls are
discarded - or maybe they are discarded immediately. Unfortunately, this
didn't mean packets are blocked but the whole firewall-1's filtering subsystem
is bypassed and packets are accepted (though ip forwarding is disabled and it
is thus not possible to gain access to systems behind the firewall).

This is as far as I understand (or could deduce from) what happens. A solution
was presented to me by Jordi Buch (thanks!): create a new icmp service
definition called evil-ping to match the following:

icmp, icmp_type=ICMP_ECHO,ip_off&0x2000!=0

This,solved the ping filtering problem, but it's more like "symptom-fighting"
than really solving the cause of the problem, which I still haven't found and
I'm still puzzled. So if anybody knows....

Arjan Vos
KPMG EDP Auditors


--------------------- insterted message 11/14/96 ----------------------------

Hi,

>> I read your note relating to the problem above and after speaking with
>> Checkpoint support I would like to know if you actually managed to
>> halt the GUI and also get a telnet session to the firewall ignoring
>> the rules database.
>>
>> Checkpoint's reply to me was they were unable to reproduce the problem
>> and saw it as an operating system fault and that FW-1 code would not
>> allow an illegal connection through.

Checkpoint is correct about that. What happened is that my client had two
entrypoints through their firewall. The regular Internet-connection over the
Ethernet-interface and a dialup PPP-conncection over the serial interface. For
the sake of logging we had kernel logging via syslog concerning the PPP as
well as direct kernel logging by Firewall-1.  So there's two kinds of kernel
logging (bad idea!).

Also a Motif GUI (FWGUI instead of FW-1's standard FWUI) was used, which
actually isn't a very good idea for our Solaris version of FW-1 (Checkpoint
pointed that out to me, and from then on a lot of additional problems were
explainable... so I suppose they were right)

So what happens is that the large ping (I used a modified ping for that, which
also can be found on the ping o'death homepage) kept the FW-1's logging busy and
locked the GUI (had something to do with Solaris' way of handling the Motif
X-server type of pipes... and that is the reason why our GUI was a bad
choice). Then I used NetCat to open a TCP stream on port 23 on the firewall
over the Internet-connection.... 

Now, telnet in is only allowed through the serial PPP-connection and we made a
entry in inetd.conf which starts up a modified TCP-wrapper to handle just
that. But somehow the kernel could not distignuish the incoming packets over
the Ethernet-interface from the incoming packets over the PPP-interface and
the logging got all mixed up by having system calls interrupting each other
and restarting them again so that the logging subsystem also went crazy.

It must be stated that the FW-1 filter on its turn is able to distinguish
packets over the Ethernet-interface from packets over the PPP-interface but my
client actually allowed incoming PPP packets in those rules by not having the
rules processing those packets. Also maybe UNIX way of implementing scheduling
algorithms and round-robin algorithms is not fully stable as deadlocks and
racing conditions may occur!!! Maybe I'll try to write a article of what
happened as it should make a pretty good horror story so good it's beyond
imagination :-))

This is a pretty much simplified explanation, but it shows again how complex
configuration and implementation issues are and that a firewall should always
be dedicated for its main functions!!! Also I think firewall suppliers should
try to document all these issues as much as possible and should inform their
clients about those things and they should explicitly list some kind of "do's
and don'ts" concerning the configuration and implementation of their products.
Besides that some implementation issues are not well explained in supplier's
manuals so that errors in the configuration are easily made.

Also, once again this proves that firewall testing is necessary and that each
implementation of a firewall has it's own possible vulnerabilities!

Arjan Vos
KPMG EDP Auditors
Right, now that that's sorted, here's how to use firewall-1 to block the Ping O' Death. Contributed by Alastair Young, with help from K.Y. Liu

This is the latest version of the rule, as of 1-November-96. This works on Firewall-1 v2.1, but not under v1.2.1 


Create a new icmp service definition called evil-ping to match the following:

icmp, icmp_type=ICMP_ECHO,ip_off&0x2000!=0

Put a rule at the top of your filters matching this with an all,all,drop
Note: This is an improvement over the previous filter which was advertised here. Checking the ip_len is not much good, because packets of >64K fragment into smaller chunks, which could be smaller then the size you are checking for. This filter blocks fragmented pings altogether, which should keep out anything larger than your MTU - pretty much anything up to 512 bytes or so is OK.