bugtraq - ICACLS.EXE ignores and destroys SE_DACL_PROTECTED/SE_SACL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <8C36CE372FBA4E3AA338515656252902@localhost>
Date: Sun, 13 May 2012 20:26:44 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <bugtraq@...urityfocus.com>
Cc: <full-disclosure@...ts.grok.org.uk>
Subject: ICACLS.EXE ignores and destroys SE_DACL_PROTECTED/SE_SACL_PROTECTED

Hi @ll,

since Windows Vista resp. Windows Server 2003 Service Pack 2, the
command line tool to modify/set file/directory permissions is
ICACLS.EXE [0][1][2][3][4].

Main advantage over the previous command line tools CACLS.EXE [5],
XCACLS.EXE [6] and XCACLS.VBS [7] is the ability to specify
inheritance and to process/propagate inheritable permissions.

But exactly the handling of inheritance is severely broken: in an
objects security descriptor both DACLs and SACLs can be marked as
"PROTECTED", meaning that inheritable ACEs from the parent object
are NOT to be applied to an object and its children [8][9].

ICACLS.EXE, when operating on an object with protected ACLs, but
1. ignores this protection,
2. resets/destroys the protection
   and
3. applies/propagates the inheritable permissions from the parent
   to the object and its children.

This (typically) results in lesser protection of the modified object
and its children, since ACLs that were neither present on the object
before nor specified as arguments to ICACLS.EXE are added to the
object and (propagated to) its children.

The following batch demonstrates the bug (the "D:P" in the SDDL [10]
representation of the security descriptors gets changed to "D:") and
reverts the changes^Wdamage done:

--- *.CMD ---
For %%X In ("%USERPROFILE%"
            "%ALLUSERSPROFILE%"
            "%SystemRoot%\Connection Wizard"
            "%SystemRoot%\Debug\UserMode"
            "%SystemRoot%\System32\Config\SystemProfile"
            "%SystemRoot%\System32\SPOOL\Printers) Do Call :ICACLS "%%~fX\."
Rem "\." is necessary due to another bug in ICACLS.EXE:
Rem  /Restore interprets pathnames different from /Save when the pathname
Rem   is a directory!
Exit /B

:ICACLS
"%SystemRoot%\System32\ICACLS.EXE" "%~1" /Save "%TEMP%\BEFORE.ACL" /C /T
"%SystemRoot%\System32\ICACLS.EXE" "%~1" /Deny *S-1-1-0:(OI)(IO)(X)
"%SystemRoot%\System32\ICACLS.EXE" "%~1" /Save "%TEMP%\AFTER.ACL" /C /T
"%SystemRoot%\System32\ICACLS.EXE" "%~1" /Restore "%TEMP%\BEFORE.ACL" /C
"%SystemRoot%\System32\FC.EXE" /U "%TEMP%\BEFORE.ACL" "%TEMP%\AFTER.ACL"
Del "%TEMP%\BEFORE.ACL" "%TEMP%\AFTER.ACL"
--- EOF ---

Vendor was informed and has acknowledged the bug, but won't neither
issue an immediate fix nor even a warning note stating the bug.

regards
Stefan Kanthak

[0] <http://support.microsoft.com/kb/919240>
[1] <http://support.microsoft.com/kb/943043>
[2] <http://support.microsoft.com/kb/944820>
[3] <http://support.microsoft.com/kb/947870>
[4] <http://support.microsoft.com/kb/2028627>
[5] <http://support.microsoft.com/kb/135268>
[6] <http://support.microsoft.com/kb/318754>
[7] <http://support.microsoft.com/kb/825751>
[8] <http://msdn.microsoft.com/library/aa374920.aspx>
[9] <http://msdn.microsoft.com/library/aa379566.aspx>
[10] <http://msdn.microsoft.com/library/aa379570.aspx>