Bugtraq mailing list archives
[Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs
From: "Stefan Kanthak" <stefan.kanthak () nexgo de>
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
Current thread:
- [Win32-API] SetNamedSecurityInfo() IGNORES and DESTROYS protected DACLs/SACLs Stefan Kanthak (Jun 19)