COMMAND
Novell Directory Services (NDS)
SYSTEMS AFFECTED
Novell Netware
PROBLEM
Following is based on a Foghorn Security Advisory. 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.
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.
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.
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.
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.
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.
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.
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.
SOLUTION
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]
[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.
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. 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.
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.