Checkpoint FireWall-1 V4.0: possible bug in LDAP authentication

From: Olaf Selke (Olaf.Selkeat_private)
Date: Wed Oct 20 1999 - 08:00:02 PDT

  • Next message: rfpat_private: "Last weeks release: whisker (new web scanner)"

    Overwiew:
    
    With FireWall-1 Version 4.0 Checkpoint introduced support for the
    Lightweight Directory Access Protocol (LDAP) for user authentication.
    It looks like there's a bug in Checkpoint's ldap code which under
    certain circumstances can lead to unauthorized access to protected
    systems behind the firewall.
    
    
    Technical background:
    
    A user can authenticate himself at the firewall providing a valid
    username and password. The firewall acts as a ldap client, validating
    the credentials by a directory server using the ldap protocol. After
    successful authentication access will be granted to systems protected
    by the firewall.
    
    In contrast to authentication using the Radius or SecurID protocol,
    after successful authentication the directory server can supply the
    firewall with additional ldap attributes for the user like the time
    and day of a week a user is allowed to login, the source addresses
    a user can run a client from, or the system behind the firewall a user
    is allowed to access. This can be done individual for each user.
    
    In general I think that's a great idea but it seems Checkpoint made
    something wrong interpreting the ldap attribute 'fw1allowed-dst' which
    is supposed to control in detail which protected network object a user
    can access.
    
    It seems this attribute is ignored by the firewall software, granting
    access to all protected network objects instead.
    
    
    Example:
    
                         ------ Server 'Foo'
                         |
    Internet --- FW-1 ---|
                         |
                         ------ Server 'Bar'
    
    
    Supposed there's a user 'Sid' with access only to Server 'Foo', and
    a second user 'Nancy' with access restricted to Server 'Bar', both
    controlled by the ldap protocol, using the ldap attribute
    'fw1allowed-dst'. The bug will cause that both, Sid and Nancy, will
    have access to Foo and to Bar.
    
    
    Conclusion:
    
    I don't consider it as major bug, but it's serious enough that one can't
    rely on access control enforced through ldap. I've reported this problem
    through Checkpoint's support channels two weeks ago, but so far there's
    no response at all.
    
    Attached is the original bug report I've sent to technical support.
    
    Olaf
    --
    Olaf Selke, olaf.selkeat_private, voice +49 5241 80-7069
    
    
    =============================== snip ===============================
    
    firewall: Solaris 2.6, V4.0 SP4 [VPN + DES + STRONG]
    management machine: Solaris 2.6, V4.0 SP4 [VPN + DES + STRONG]
    Directory Server: Solaris 7, Netscape-Directory/4.0 B98.349.0339
    
    
    Today we found that FW-1 seems to ignore the ldap attribute
    'fw1allowed-dst' completely, granting access to 'any' instead.
    If that's really the case, it could lead to a breach of security.
    
    We successfully coupled a FW-1 V4.0 SP4 with a Netscape Directory
    Server according CP's documentation. Surprisingly this went very
    smoothly ;-) In a second step we checked if the FW software really
    cares about the ldap attributes controlling access in detail, using a
    client authentication rule for this purpose.
    
    It looks like the attributes 'fw1hour-range-from', 'fw1hour-range-to',
    and 'fw1allowed-src' are interpreted as expected by the firewall, so
    I think we didn't made some mistake in general.
    
    However, from our point of view, in any case the ldap attribute
    'fw1allowed-dst' is ignored and silently substituted by 'any'.
    This means a user with restricted access through ldap attributes
    has full access after successful authentication.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:02 PDT