Issue description

Windows: StorSvc SvcMoveFileInheritSecurity Arbitrary File Security Descriptor Overwrite EoP
Platform: Windows 10 1709 (not tested earlier versions)
Class: Elevation of Privilege
Summary: The SvcMoveFileInheritSecurity RPC method in StorSvc can be used assign an arbitrary security descriptor to an arbitrary file leading to EoP.
Description:
Note this is a second bug in the same function. I’m submitting it separately just to ensure that the resulting fix doesn't miss this edge case as well.
I was reading Clément Rouault & Thomas Imbert excellent PacSec’s slides on ALPC+RPC issues and they highlighted the SvcMoveFileInheritSecurity method used to exploit the ALPC bug CVE-2017-11783. The function impersonates the user and calls MoveFileEx to move the file to a new destination, then reverts the impersonation and tries to reset the security descriptor of the new file so that it matches the inheritable permissions. The ALPC bug in CVE-2017-11783 has apparently been fixed but the behavior of the SvcMoveFileInheritSecurity has not been modified as far as I can tell.
The problem occurs if SvcMoveFileInheritSecurity is used to move a hardlinked file. It’s possible using the native APIs to hardlink to a file that the user can only read. As long as the directory the link is in grants the user delete file access then even though requesting DELETE fails on the file’s security descriptor it’s granted based on the parent directory. This allows the MoveFileEx call to succeed when being called under impersonation.
If the file is moved to a directory which has inheritable ACEs which would grant the user access then when the server calls SetNamedSecurityInfo it will apply the inherited ACEs onto the file as the API assumes that the parent is the folder the file is currently linked into to, not the location that the file was originally in. As this is performed as SYSTEM this means that any file can be given an arbitrary Security Descriptor which would allow a user to modify it.
Proof of Concept:
I’ve provided a PoC as a C++ project. It will abuse the SvcMoveFileInheritSecurity method to create the file test.txt in the windows folder.
1) Compile the C++ project.
2) Execute the PoC as a normal user passing the path to a file on the system drive on the command line which you want to overwrite the security descriptor.
Expected Result:
The file move fails.
Observed Result:
The target file has had it’s security descriptor rewritten to allow access to everyone.
This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.

After reviewing the patch for this issue MS have not fixed it even though the report was quite specific about not forgetting about this edge case. Therefore as it's not actually fixed the status has been reverted to New.

Some additional notes about this issue. Firstly based on the fix for issue 1427 (https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0826) this only affects Windows 10, it does not affect any earlier versions of Windows such as 7 or 8.1. However I've not verified that to be the case but there's no reason to believe it's incorrect.
MS consider this to be an 'Important' issue, but crucially not a 'Critical' issue. This is because this issue is an Elevation of Privilege which allows a normal user to gain administrator privileges. However in order to execute the exploit you'd have to already be running code on the system at a normal user privilege level. It cannot be attacked remotely (without attacking a totally separate unfixed issue to get remote code execution), and also cannot be used from a sandbox such as those used by Edge and Chrome. The marking of this issue as High severity reflects the ease of exploitation for the type of issue, it's easy to exploit, but it doesn't take into account the prerequisites to exploiting the issue in the first place.