OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: adariensecuretrendz.com
Date: Fri Sep 07 2001 - 20:18:31 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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