[Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs
- From: "Stefan Kanthak" <stefan.kanthak@xxxxxxxx>
- Date: Tue, 19 Jun 2012 18:38:34 +0200
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
- Prev by Date: VUPEN Security Research - Microsoft Internet Explorer "Col" Element Remote Heap Overflow (MS12-037 / CVE-2012-1876)
- Next by Date: [Announcement] ClubHack Magazine Issue 29, June 2012 Released
- Previous by thread: VUPEN Security Research - Microsoft Internet Explorer "Col" Element Remote Heap Overflow (MS12-037 / CVE-2012-1876)
- Next by thread: [Announcement] ClubHack Magazine Issue 29, June 2012 Released
- Index(es):
Relevant Pages
|
