Fw: Bypassing Inherited Rights Filters in Novell Directory Services. (fwd)

[William Diehl III <willdieh () LASIERRA EDU>]

Has this been verified by Foghornsecurity.com?

When attempting to replicate the procedure as listed below, I was unable to
repeat the security risk.

As I understand it, IRFs and explicit rights access work PROPERLY and in the
following fashion:


-    An IRF will filter INHERITED rights

-    An IRF will NOT filter any explicit rights to any objects AT OR BELOW
the IRF level in the tree

-    Because the procedure below adds the "Write" right to the ACL of the OU
ABOVE the IRF and sets it as INHERITABLE, it _will_ be blocked by the IRF
because 1. it becomes an inherited right and 2. the explicit assignment is
made above the IRF



I am running Netware 5.0 service pack 5 with eDirectory (NDS 8).

If this has indeed been verified and repeated by someone else, please let me
know

William Diehl
Network Administrator
LaSierra University
Riverside, CA




> ---------- Forwarded message ----------
> Date: Thu, 7 Sep 2000 19:24:00 -0700
> From: FogHorn Security <info () FOGHORNSECURITY COM>
> To: BUGTRAQ () SECURITYFOCUS COM
> Subject: Bypassing Inherited Rights Filters in Novell Directory Services.
>
>                              FOGHORN SECURITY ADVISORY
>
>                                       issued
>
>                                  September 7, 2000
>
>                 http://www.foghornsecurity.com/advisories/20000907
>
>           Bypassing Inherited Rights Filters in Novell Directory Services.
>
>
>
>
> SUMMARY
>
> A design weakness in NDS as shipped with Novell v5.0 and later
> can allow certain users to bypass IRF's, and gain escalation of
privileges.
> SEVERITY
> Serious.  Even in a well designed tree IRF's are sometimes needed to
protect
> more sensitive objects.  This issue, if not carefully considered, can
easily
> render IRF's ineffective, and expose sensitive information.
>
> BACKGROUND
>
> In NDS, rights are assigned in three ways:
>
> Rights to an object [Object Rights]
> Rights to all properties of an object [All Properties Rights]
> Rights to selected properties of an object [Selected Properties Rights]
>
> By default, rights granted at one level of a directory tree automatically
> flow down to lower levels in the tree.  This inheritance of rights can be
> blocked by using Inherited Rights Filters [IRFs].  IRFs can be set for
> any of the three types of rights mentioned above.
>
> THE PROBLEM
>
> In previous versions of NDS, only Object Rights, and All Properties Rights
> could be inherited.  In Netware 5.0, Novell added the ability to make
> Selected Property Rights inheritable.  These rights are not blocked by
> IRFs set for Object Rights or All Properties Rights.  They can only be
> blocked by the creation of an explicit IRF for each property you need to
> protect.
>
> Obviously, this is unworkable in the real world.  Setting individual IRFs
> for every property in the schema is tedious and prone to error, and it is
> extremely difficult to anticipate all possible exploits for all
properties.
> Additionally, if the schema is extended, the new properties would be
> unprotected until IRFs were updated.
>
> This also presents a problem for sites upgrading from Novell 4.11.  If
this
> issue is not addressed in the upgrade process, IRF's which were previously
> valid, could be rendered ineffective.
>
> EXPLOIT
>
> Active exploitation of this feature requires Write rights to the Object
> Trustees ACL property of a container at or above the level of the object
being
> attacked.
>
> Here's an example. An administrator, .BOB.ACME, has Supervisor [S] rights
to
> the .ACME container. There is a container, .SECRET.ACME, which BOB should
not
> have any access to.
>
> Joe, .JOE.SECRET.ACME, is the administrator of .SECRET.ACME.  Joe has
> been given S rights to SECRET, and an IRF has been put in place on SECRET
> blocking all Object Rights, and all All Properties Rights.  This scenario
is in
> line with standard practice, and Novell's own documentation [See TID#
10011973]
> Unfortunately, Bob can still gain full control of secret.
>
> 1] Bob modifies the trustees list of .ACME granting himself the Write [W]
> right to the Object Trustees ACL property and designates this right as
> inheritable.
>
> 2] Since Selected Properties Rights are not explictly blocked by the IRF
> at .SECRET.ACME, Bob can now add himself to the trustee list of the
> SECRET container and obtain full privileges.
>
>
> OTHER CONSIDERATIONS
>
> In addition to active exploits, this issue could result in administrators
> inadvertently granting rights to objects they believe to be protected by
IRF's.
> For instance, Help Desk staff may be granted password reset rights by
granting
> Selected Properties Rights at a high level in the tree, and making those
rights
> inheritable.  Those rights can only be blocked with an explicit Selected
> Properties IRF at the containers or objects you need protected.
>
> WORKAROUND
>
> It is impossible to anticipate all the scenarios where this *feature*
> could be exploited.  Administrators should carefully evaluate their tree
> and permission structures with this problem in mind.
>
> At a minimum, where IRFs are used to protect objects or containers, the
> following properties should be protected by explicit IRFs:
>
> Object Trustees [ACL]
> Members
> Security Equal to Me
> Password Required
> Password Management
> Incorrect Login Attempts
>
> There are certainly others that would need to be protected as well.
> Finding additional exploits is left as an exercise for the reader.
> [Hint: Audit Objects]
>
> FIX
>
> We believe that Novell should either,
>
> a) Make IRFs set for All Properties Rights apply to Selected Properties
>    Rights as well
>
> or
>
> b) Provide a method whereby all Selected Properties Rights could be
> filtered with a single IRF.
>
> COMMENTS
>
> This is a classic example of adding functionality without fully
considering the
> implications.  While we do not consider this to be a *bug*, it is clearly
a
> poorly designed *feature*.  We could not find any reference to this on
Novell's
> support website.  In fact, as referenced above, Novell's own documentation
> [TID# 10011973 - last updated on June 29, 2000] does not address this
issue.
> In that document, they answer the question, "How do I create an admin for
a
> container that cuts off the main admin?"  They do not specify the
filtering of
> Selected Properties Rights, and thus leave readers open to this
vulnerability.
> Safe Computing,
>
> -FogHorn Security Staff