exploit the possibilities

SetNamedSecurityInfo() Ignores / Destroys Protected DACLs / SACLs

SetNamedSecurityInfo() Ignores / Destroys Protected DACLs / SACLs
Posted Jun 19, 2012
Authored by Stefan Kanthak

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.

tags | advisory
systems | windows, 2k, 32
MD5 | 0ed4f85fb35e5a60a55c2633b90b012d

SetNamedSecurityInfo() Ignores / Destroys Protected DACLs / SACLs

Change Mirror Download
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

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

February 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    1 Files
  • 2
    Feb 2nd
    2 Files
  • 3
    Feb 3rd
    17 Files
  • 4
    Feb 4th
    15 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    16 Files
  • 7
    Feb 7th
    19 Files
  • 8
    Feb 8th
    1 Files
  • 9
    Feb 9th
    2 Files
  • 10
    Feb 10th
    15 Files
  • 11
    Feb 11th
    20 Files
  • 12
    Feb 12th
    12 Files
  • 13
    Feb 13th
    18 Files
  • 14
    Feb 14th
    17 Files
  • 15
    Feb 15th
    4 Files
  • 16
    Feb 16th
    4 Files
  • 17
    Feb 17th
    34 Files
  • 18
    Feb 18th
    15 Files
  • 19
    Feb 19th
    19 Files
  • 20
    Feb 20th
    20 Files
  • 21
    Feb 21st
    15 Files
  • 22
    Feb 22nd
    2 Files
  • 23
    Feb 23rd
    2 Files
  • 24
    Feb 24th
    16 Files
  • 25
    Feb 25th
    37 Files
  • 26
    Feb 26th
    15 Files
  • 27
    Feb 27th
    15 Files
  • 28
    Feb 28th
    4 Files
  • 29
    Feb 29th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close