Date: 8 Sep 2001 01:18:31 -0000
From: [email protected]
To: [email protected]Subject: Bug in compile portion for older versions of CheckPoint Firewalls
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
