New issue
Advanced search Search tips

Issue 1428 link

Starred by 3 users

Issue metadata

Status: Fixed
Merged: issue 1427
Closed: Mar 2018

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Windows: StorSvc SvcMoveFileInheritSecurity Arbitrary File Security Descriptor Overwrite EoP

Project Member Reported by, Nov 10 2017

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.


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.
26.7 KB Download
Project Member

Comment 1 by, Nov 13 2017

Labels: MSRC-42121
Project Member

Comment 2 by, Jan 29 2018

Mergedinto: 1427
Status: Duplicate (was: New)
Marking as duplicate.
Project Member

Comment 3 by, Feb 18 2018

Status: New (was: Duplicate)
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.
Project Member

Comment 4 by, Feb 20 2018

For information this is the reporting timeline:

> 2017-11-10 -  Issue 1427  and  1428  reported to MSRC via
< 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.

Project Member

Comment 5 by, Feb 20 2018

Labels: Deadline-Exceeded Deadline-Grace
Made issue public.
Project Member

Comment 6 by, Feb 20 2018

Labels: -Restrict-View-Commit
Project Member

Comment 7 by, Feb 21 2018

Some additional notes about this issue. Firstly based on the fix for  issue 1427  ( 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.
Project Member

Comment 8 by, Mar 13 2018

Labels: CVE-2018-0983
Status: Fixed (was: New)
Fixed in
Project Member

Comment 9 by, Apr 18 2018

Uploaded a full POC.
17.9 KB Download

Sign in to add a comment