Hi @ll,

the following is a substantially shortened version of
<https://skanthak.homepage.t-online.de/quirks.html#quirk15> and
<https://skanthak.homepage.t-online.de/quirks.html#quirk16>


Windows NT supports access control for (almost) all its objects,
<https://technet.microsoft.com/en-us/library/cc781716.aspx>
"How Security Descriptors and Access Control Lists Work" and
<https://technet.microsoft.com/en-us/library/cc783530.aspx>
"How Permissions Work" provide a comprehensive and exhaustive explanation.

<https://msdn.microsoft.com/en-us/library/aa374872.aspx>
"Access Control Lists" provides an abstract:

| An access control list (ACL) is a list of access control entries (ACE).
| Each ACE in an ACL identifies a trustee and specifies the access rights
| allowed, denied, or audited for that trustee. The security descriptor
| for a securable object can contain two types of ACLs: a DACL and a SACL.
|
| A discretionary access control list (DACL) identifies the trustees that
| are allowed or denied access to a securable object. When a process tries
| to access a securable object, the system checks the ACEs in the object's
| DACL to determine whether to grant access to it. If the object does not
| have a DACL, the system grants full access to everyone. If the object's
| DACL has no ACEs, the system denies all attempts to access the object
| because the DACL does not allow any access rights. The system checks the
| ACEs in sequence until it finds one or more ACEs that allow all the
| requested access rights, or until any of the requested access rights are
| denied. [...] 


False claim #1
~~~~~~~~~~~~~~

<https://msdn.microsoft.com/en-us/library/aa364399.aspx>
"File Security and Access Rights" specifies for directories and files:

| The valid access rights for files and directories include the DELETE,
| READ_CONTROL, WRITE_DAC, WRITE_OWNER, and SYNCHRONIZE standard access
| rights. 
...
| By default, authorization for access to a file or directory is controlled
| strictly by the ACLs in the security descriptor associated with that file
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| or directory. In particular, the security descriptor of a parent directory
| is not used to control access to any child file or directory.

REALLY?


Demonstration #1
~~~~~~~~~~~~~~~~

Run the following command lines to prove the above claim wrong for files:

| CHDIR /D "%PUBLIC%"
| REM create an empty file
| COPY NUL: file
|         1 file(s) copied.
| REM remove all (inherited) ACEs
| ICACLS.exe file /Inheritance:R
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) read the file
| TYPE file
| Access denied
|
| REM display the (now empty) DACL
| CACLS.exe file /S
| C:\Users\Public\file "D:PAI"

Although the (empty) DACL grants no access, the object's owner has
(documented) implicit READ_CONTROL access permission (and WRITE_DAC too)!

| REM add an ACE to deny the owner's implicit access permissions
| ICACLS.exe file /Deny *S-1-3-4:(F)
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) display the DACL
| CACLS.exe file /S
| C:\Users\Public\file
|
| Access denied
|
| REM delete the file
| ERASE file

Although even the owner had no access any more, the file is gone:
<https://msdn.microsoft.com/en-us/library/aa363915.aspx>
"DeleteFile function",
<https://msdn.microsoft.com/en-us/library/aa363916.aspx>
"DeleteFileTransacted function",
<https://msdn.microsoft.com/en-us/library/aa365240.aspx>
"MoveFileEx function",
<https://msdn.microsoft.com/en-us/library/aa365242.aspx>
"MoveFileWithProgress function",
<https://msdn.microsoft.com/en-us/library/aa365513.aspx>
"ReplaceFile function" tell why, and contradict the above claim!

| To delete or rename a file, you must have either delete permission on
| the file, or delete child permission in the parent directory.


Demonstration #2
~~~~~~~~~~~~~~~~

Run the following command lines to prove the above claim also wrong for
directories:

| CHDIR /D "%PUBLIC%"
| REM create an empty directory
| MKDIR directory
| REM remove all (inherited) ACEs
| ICACLS.exe directory /Inheritance:R
| processed file: directory
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) list the directory
| DIR directory
...
| File not found
|
| REM (try to) remove the directory
| RMDIR directory
| Access denied

Works as designed and documented!
BUT: contrary to "file" child objects, DELETE_CHILD permission on the
     parent directory does NOT allow removal of "directory" child objects!

| REM display the (now empty) DACL
| CACLS.exe directory /S
| C:\Users\Public\file "D:PAI"

Although the (empty) DACL grants no access, the object's owner has (documented)
implicit READ_CONTROL access permission (and WRITE_DAC too)!

| REM add an ACE with only SYNCHRONIZE to deny the implicit access permissions
| ICACLS.exe directory /Grant *S-1-3-4:(S)
| processed file: directory
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) display the DACL
| CACLS.exe directory /S
| C:\Users\Public\directory
|
| Access denied
|
| REM remove the directory
| RMDIR directory

OUCH: although no DELETE permission was granted the directory is gone!

Bug^WVULNERABILITY or feature?
See the vendor statement below!


False claim #2
~~~~~~~~~~~~~~

<https://msdn.microsoft.com/en-us/library/aa379321.aspx> "SACL Access Right"

| The ACCESS_SYSTEM_SECURITY access right is not valid in a DACL because
| DACLs do not control access to a SACL.

REALLY?


False claim #3
~~~~~~~~~~~~~~

<https://msdn.microsoft.com/en-us/library/aa379315.aspx>
"Requesting Access Rights to an Object"

| (!) Note
|
| The MAXIMUM_ALLOWED constant cannot be used in an ACE.

REALLY?


Demonstration #3
~~~~~~~~~~~~~~~~

| CHDIR /D "%PUBLIC%"
| REM create an empty file
| COPY NUL: file
|         1 file(s) copied.
| REM remove all (inherited) ACEs
| ICACLS.exe file /Inheritance:R
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) add ACEs with ACCESS_SYSTEM_SECURITY and MAXIMUM_ALLOWED access permissions
| ICACLS.exe file /Deny *S-1-1-0:(AS) /Grant *S-1-1-0:(MA)
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM display the DACL
| CACLS.exe file /S
| C:\Users\Public\file "D:PAI"

OOPS: despite the "success" message no ACEs were added!

| REM second try
| ICACLS.exe file /Deny *S-1-3-4:(AS) /Grant *S-1-3-4:(MA) /Grant "%USERNAME%":(F)
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM display the DACL
| CACLS.exe file /S
| C:\Users\Public\file "D:PAI(D;;;;;OW)(A;;FA;;;S-1-5-21-3150931553-3643200234-2488609525-1000)(A;;;;;OW)"

OUCH: both (AS) and (MA) create ACEs WITHOUT any access permission!

| REM display the DACL again
| ICACLS.exe file
| file OWNER RIGHTS:(DENY)(S)
|      AMNESIAC\Stefan:(F)
|      OWNER RIGHTS:

OOPS: ICACLS.exe shows (S) "SYNCHRONIZE" access permission despite
      that NO_ACCESS is present!

| REM remove the deny ACE for the owner and the allow ACE for the user,
| REM leaving the allow ACE for the owner
| ICACLS.exe file /Remove:d *S-1-3-4 /Remove:g "%USERNAME%"
| processed file: file
| Successfully processed 1 files; Failed processing 0 files
|
| REM (try to) display the DACL
| CACLS.exe file /S
| C:\Users\Public\file
|
| Access denied

OUCH: the allow ACE with empty access mask REMOVES the owner's implicit
      READ_CONTROL and WRITE_DAC access permissions!

| ERASE file

See above!

JFTR: these demonstrations uncover just the tip of the iceberg!


Vendor statement
~~~~~~~~~~~~~~~~

| Thank you for your submission. We determined your finding does not meet
| our bar for immediate servicing. For more information, please see the
| Microsoft Security Servicing Criteria for Windows
| (https://aka.ms/windowscriteria).
|
| However, we've marked your finding for future review as an opportunity
| to improve our products. I do not have a timeline for this review and
| will not provide updates moving forward. As no further action is
| required at this time, I am closing this case. You will not receive
| further correspondence regarding this submission.


stay tuned, and far away from defective products!
Stefan Kanthak