full-disclosure - [FD] Defense in depth -- the Microsoft way (part 77): access without access permission

Open Source and information security mailing list archives

Message-ID: <68F31D13B21C42D7B4EFE6FE63E604D0@H270>
Date: Fri, 14 May 2021 19:03:59 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: <fulldisclosure@...lists.org>
Cc: bugtraq@...urityfocus.com
Subject: [FD] Defense in depth -- the Microsoft way (part 77): access
	without access permission

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:

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:

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
~~~~~~~~~~~~~~~~

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

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

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