[Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs

["Stefan Kanthak" <stefan.kanthak@xxxxxxxx>]

Hi @ll,

(this is the prequel to <http://seclists.org/bugtraq/2012/May/75>
alias <http://seclists.org/fulldisclosure/2012/May/109>)

With Windows 2000 Microsoft introduced the inheritance of access
rights and new Win32-API functions like SetNamedSecurityInfo()
which handle the inheritance.

SetNamedSecurityInfo() but has a serious bug: it applies inheritable
ACEs from a PARENT object to a target object even if it must not do so,
indicated by the flags SE_DACL_PROTECTED and/or SE_SACL_PROTECTED in
the security descriptor of the target object.

This erroneous behaviour can result in lesser protection of any target
object whose security descriptor is changed with SetNamedSecurityInfo().


>From the official documentation:

<http://msdn.microsoft.com/en-us/library/aa376326.aspx>

| When you call the SetNamedSecurityInfo and SetSecurityInfo functions 
| to set the security information of an object, the system imposes the 
| current inheritance model on the ACLs of all objects in the hierarchy 
| below the target object.
  ~~~~~~~~~~~~~~~~~~~~~~~


<http://msdn.microsoft.com/en-us/library/aa379579.aspx>

| Remarks
|
| If you are setting the discretionary access control list (DACL) or 
| system access control list (SACL) of an object, the system 
| automatically propagates any inheritable access control entries (ACEs) 
| to existing child objects, according to the rules of inheritance.
  ~~~~~~~~~~~~~~~~~~~~~~~~~


<http://msdn.microsoft.com/en-us/library/aa374920.aspx>

| These rules have been enhanced with the following features:
...
| The ability to prevent a DACL or SACL from inheriting ACEs by setting 
| the SE_DACL_PROTECTED or SE_SACL_PROTECTED bits in the security 
| descriptor's control bits.


<http://technet.microsoft.com/en-us/library/cc781716.aspx>

| SE_DACL_PROTECTED Windows 2000 and later: The security descriptor's
|                   DACL cannot be modified by inheritable ACEs.
|
|                   If this flag is not set, the security descriptor
|                   inherits information from the security descriptor
|                   of the parent object.
...
| SE_SACL_PROTECTED Windows 2000 and later: The security descriptor's
|                   SACL cannot be modified by inheritable ACEs.
...
| ... sets the security descriptor control flag SE_DACL_PROTECTED, which 
| protects a child object's DACL by blocking inheritance from the parent 
| object's DACL.


<http://msdn.microsoft.com/en-us/library/aa379566.aspx>

| SE_DACL_PROTECTED
| 0x1000            Prevents the DACL of the security descriptor from
|                   being modified by inheritable ACEs.  To set this
|                   flag, use the SetSecurityDescriptorControl function.
...
| SE_SACL_PROTECTED
| 0x2000            Prevents the SACL of the security descriptor from
|                   being modified by inheritable ACEs.  To set this
|                   flag, use the SetSecurityDescriptorControl function.


To demonstrate the error call the example code from <http://msdn.microsoft.com/en-us/library/aa379283.aspx>
as follows:

#include <windows.h>
#include <tchar.h>
#include <aclapi.h>

int _tmain()
{
    return AddAceToObjectsSecurityDescriptor (
        TEXT("%ALLUSERSPROFIL%"), // specify your path here!
        SE_FILE_OBJECT,
        TEXT("S-1-1-0"),
        TRUSTEE_IS_NAME,
        FILE_EXECUTE,
        DENY_ACCESS,
        OBJECT_INHERIT_ACE | INHERIT_ONLY_ACE); }


In all current versions of Windows the directory "%ALLUSERSPROFILE%"
has SE_DACL_PROTECTED flag set in its security descriptor... before
the call. Afterwards, SE_DACL-PROTECTED is gone, and "%ALLUSERSPROFILE%"
got additional inherited access rights.


regards
Stefan Kanthak