Windows: StorSvc SvcMoveFileInheritSecurity Arbitrary File Security Descriptor Overwrite EoP
Project Member Reported by firstname.lastname@example.org, Nov 10 2017
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.
Nov 13 2017,
Jan 29 2018,
Marking as duplicate.
Feb 18 2018,
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.
Feb 20 2018,
For information this is the reporting timeline: > 2017-11-10 - Issue 1427 and 1428 reported to MSRC via email@example.com. < 2017-11-11 - MSRC responds indicating the reports have been received and that new cases would be issued on Monday. < 2017-11-13 - MSRC issue case 42122 for issue 1427 and 42121 for issue 1428 . < 2017-11-24 - MSRC sends emails for issue 1427 that it's been reproduced and awaiting finish of investigation to determine whether it'll be fixed in a security release. < 2017-11-29 - MSRC sends emails for issue 1428 that it's been reproduced. MSRC requests the deadline grace extension to allow issues to be fixed on 13th Feb 2018. MSRC indicates that they are tracking 1428 as a duplicate of 1427. > 2017-11-29 - Confirmed deadline grace extension. < 2017-12-23 - MSRC confirm issues on track for fix in Feb 2018. < 2018-01-05 - MSRC assigns CVE-2018-0826. < 2018-02-13 - MSRC issues public fix. > 2018-02-18 - Analysis of patch indicates 1427 is fixed but 1428 is not. MSRC sent an email indicating that the issue will become public on Feb 20th at 10am PST. > 2018-02-20 - Issue 1428 opened in issue tracker.
Feb 20 2018,
Made issue public.
Feb 20 2018,
Feb 21 2018,
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.
Uploaded a full POC.
Sign in to add a comment