[16670] in bugtraq
Fw: Bypassing Inherited Rights Filters in Novell Directory
daemon@ATHENA.MIT.EDU (William Diehl III)
Fri Sep 8 16:56:39 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <001401c019c1$79a67af0$35d69cc0@lasierra.edu>
Date: Fri, 8 Sep 2000 11:20:32 -0700
Reply-To: William Diehl III <willdieh@LASIERRA.EDU>
From: William Diehl III <willdieh@LASIERRA.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
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
>
>
