This mail is about something checkpoint has overlooked in it's
firewall-1 v2.1. I believe it to be a flaw in lots of ruleset
implementations anywhere.
Say I build a ruleset around the following assumptions:
First of all, I want to allow administrators access to the firewall.
Second, I want to block all other access to the firewall itself.
Third, I want to allow some services from the inside nets to the
outside.
To implemement this, one would have the following ruleset structure:
1) Allow access to firewall for adminstrator access
2) Block all other access to the firewall object
3) Allow traffic from inside net to any for certain services
Now, this will correctly block all access to the firewall's interface
addresses for non admin access. However, if you use the network
address of, say, the external interface of the firewall, as your
destination address. The ruleset will not block this in the second rule,
and it will match on the third.
In some cases (in my case on Solaris 2.5 sparc) this can actually be
used to connect to services on the firewall. I'm not sure if this works
with all tcp implementations, but I think this has something to do with
the deprecated use of the subnet address as the all-subnets directed
broadcast address. Also, I've seen this only in a situation where the
network was subnetted. I will try to reproduce this for non-subnet
situations as soon as I can find some time.
This particular problem situation is not as much a threat, as it will
only allow access to firewall services from the internal network.
However, if liberal access is allowed from outside too, this may be
exploitable from outside as well. All it takes is a rule allowing
a service to anywhere, or a network including the firewall. This will be
enough to match the network address...
A fix would be to define *host* objects for each of these network
addresses and deny access to them too in the second rule...
I sent this to bugtraq too to give checkpoint a little motivation to
look into this problem...
Tom.
--| Tom Vandepoel | Sr.Network Engineer | NetVision nv tom@netvision.be http://www.netvision.be | | T. 32-16-31.00.15 | F. 32-16-31.00.29
For geekcode and other info, check http://www.netvision.be/tom/gc.html