Followup - Bypassing IRFs in NDS

[FogHorn Security <info () FOGHORNSECURITY COM>]

"William Diehl III" <willdieh () lasierra edu> wrote:

> Has this been verified by Foghornsecurity.com?

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

Yes, this was verified in a mixed 4.11/5.0 environment.  After a couple
private email exchanges with William, we realized we forgot an important point
in our original post.

William observed that the blocked admin could not even see the SECRET
container, and therefore could not assign himself rights to it.  Since the
admin's Object Browse right was filtered, that would be a correct observation.
To gain control of the SECRET container, the admin would need to know the name
of the container, and use a third party tool [i.e. JRB Utilities] to assign the
rights.

Whether that mitigates the issue by making it more obscure, or aggrevates it
by making it more insidious, is a judgement left to the readers.

Bob Fiero <bfiero () mentalfloss net> wrote:

> If you understood NDS sufficiently, you wouldn't give Bob [S] rights to a
> container where you need to keep him from objects under that container.
> Regardless of what you do, Bob has [S] rights that you granted him, and
> those rights can be applied...as in giving himself or any other user access
> to objects within that container. How is that a bug?

Incorrect.  [S] rights within NDS CAN be blocked by IRFs.  There are
circumstances where [S] rights to the FILESYSTEM CANNOT be blocked, but that is
unrelated to this issue.

We should clarify that [S] rights are NOT needed to exploit this issue.  The
only right needed is the Write [W] right to the Object Trustees ACL property of
any container higher in the tree than the object being attacked.

Which brings us to this:

John McCain <jmccain () POMEROY COM> wrote:

> Your statements regarding this security "hole" are misleading.

> While it is true that not watching write rights to ACL's can lead to network
> problems, anyone who has undergone any level of Netware training knows the
> extent to which Novell warns against granting broad property write rights,
> specifically because of the danger of giving someone rights to another object's
> ACL.  Setting a property level IRF on the ACL property would neither be time
> consuming nor prone to error.

It's not that simple.  First, we are talking about blocking ADMINS from lower
level containers.  It's difficult to be an admin without having the ability to
modify trustee lists.

Secondly, our "time consuming and prone to error" comment was in reference to
the need for explicit IRFs on EVERY sensitive property, if the goal of blocking
all administrative access was to be achieved.  There are many more properties to
consider than just the ACL; refer to the original advisory for a partial list.

Thirdly, you seem to be ignoring our "Other Considerations".  Suppose you
need to grant a group of people limited rights for object management across
large portions of your tree. [i.e. password management].  You will probably
want to grant rights to SELECTED properties, and grant them relatively high in
the tree.  If IRFs are not properly applied [which is likely given the problem
we disclosed], those rights may well flow into unintended areas.

> The dangers of granting write property rights to ACLs is discussed extensively
> in the training materials for Novell's CNA certification, their base level of
> certification.  I suggest you review these materials before publishing similar
> warnings, or availing yourself of someone who has.

Ouch!  Excuse me while I bite my tongue, take a deep breath, and count to ten.

Well, as we pointed out, Novell itself seems to have missed this issue.  It is
a bit much to expect someone with a base level certification to understand
things the vendor itself has not yet grasped.

SO, WHY IS THIS ISSUE IMPORTANT??

We really didn't want to bring this up, but Novell went to great lengths last
February to beat up Microsoft about a bug/feature in Active Directory.  See
http://www.novell.com/competitive/nds/security.html for details.

In that article, Novell states, in fact brags, about the ability to
COMPLETELY BLOCK administrative rights to portions of the tree.
We will not debate the merits of such a feature.  We assume that it is useful,
that customers are using it, and that customers expect it to work as advertised.

Our advisory matters because:

1] Novell's own documentation incorrectly describes the process for blocking
administrative rights, and in so doing, leaves customers unprotected.

2] Novell has added new features to recent versions of its software which
undermine previously valid configurations, and has failed to notice, much less
publicize, this fact.

3] The process for blocking inherited rights is no longer intuitive.  This is
an invitation to misconfiguration.

4] A "hole" is a "hole" whether the result of coding errors, or configuration
errors.  We believe that software designs which result in a high probability of
misconfiguration are valid subjects for public comment.

And finally, in defense of Novell, we would like to reiterate that this is not
a bug [close, but not quite].  Novell's software is functioning as designed.
The ability to completely block administrative access still exists, it is just
much more difficult to achieve than previously thought.

Anyway you look at it, it needs to be fixed.

Safe Computing,

FogHorn Security Staff