Bug in compile portion for older versions of CheckPoint Firewalls

[<adarien () securetrendz com>]

There is a bug in how CheckPoint firewalls prior 
to version 4.0 SP2 handled compiling the firewall 
policy on Solaris workstations. I was actually 
migrating a client from version 4.0 SP1 when I 
stumbled on this. The vendor was contacted on 
January 30, 2001 and responded on February 2, 2001 
that they fixed it in version 4.0 SP2.

I am posting it here in hopes that customers who 
have not upgraded (suprisingly, I have come across 
a few who are "afraid" to make those transitions) 
will see this and do so.

Below in the dashes are portions of the contents 
of the email I sent to CheckPoint describing the 
bug.

--------------------------------------------------

Check Point Firewall-1 ver. 3.0b through 4.0 on 
the Solaris 2.6-2.7 (latest patches) platform

BUG found on 01/26/01 by Alan Darien, 
SecureTrendz, Inc. 


Product:        Check Point Firewall-1 ver. 3.0b 
through 4.0
Platform:       Sun Microsystem Ultra-2
Operating System:       Solaris 2.6 and Solaris 
2.7 with latest patches

I have found a bug that exists in versions of 
Check Point's Firewall. I have verified it in ver. 
3.0b and ver. 4.0.  The bug is local to the 
firewalled workstation.

Description:
When a Firewall Policy is compiled, Firewall 
compilation creates a temporary file in /tmp with 
the policy name and ".cpp" appended to it. The 
access mode of the file is rw-rw-rw- (666). A user 
can elevate their access levels by exploiting this 
knowledge.


Example:

If I have firewall remote administrative access 
with write privileges but again junior system 
administrator privileges on the firewalled 
workstation, I can:
1. Add the login service (rlogin) to the rule 
containing FW management for my workstation
2. Create a link file in /tmp with the 
policyname.cpp to /.rhosts
3. Install the modified policy and then edit 
/.rhosts to include a "+" or my specific desktop
4. Come across from root on my workstation anytime 
without having to modify the password or shadow 
files
5. If the system only allows root login at the 
console, I just add a step or two to the above to 
overwrite /etc/default/login, add the necessary 
entries and move on

Scenarios:
There are a couple of scenarios, that come to 
mind, in which the above can take place.
1. Rookie firewall administrators are given GUI 
access to the firewall to do firewall 
administration. They have been trained to add 
rules, create objects and install policies BUT are 
not trusted to have superuser access to the 
system. They don't know directory structure 
layout, system configuration, etc. but have been 
given administrative group access to do backups 
and the such.
2. Two (or more groups) administer the system at 
different levels. One group handles all system 
matters: configurations, backups, trouble-shoots 
and the other handles solely firewall issues: rule 
additions/deletions, object creations, policy 
generation.

Fixes:

1. Upgrade to latest Check Point Firewall ver. 4.1 
 and latest service pack. Check Point Firewall 
ver. 4.0 SP2 and higher places the work for the 
policy compiles under the firewall directory 
structure which is accessible only by the 
superuser (if installed properly). 

--------------------------------------------------
 

 -  Alan