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