[<prev] [next>] [day] [month] [year] [list]
Message-ID: <FC8CDDB7E1C749319FDCBBE99BD21858@localhost>
Date: Tue, 19 Jun 2012 18:38:34 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <full-disclosure@...ts.grok.org.uk>
Subject: [Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs
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
Powered by blists - more mailing lists