New issue
Advanced search Search tips

Issue 440 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2015
Cc:



Sign in to add a comment

Windows: Malicious Software Removal Tool Unsafe Temp Directory Use Elevation of Privilege

Project Member Reported by forshaw@google.com, Jun 11 2015

Issue description

Windows: Malicious Software Removal Tool Unsafe Temp Directory Use Elevation of Privilege
Platform: Tested on Windows 8.1 Update 32 bit and 64 bit, should work on 10 as well
Version: MRT 5.25.11502.0 Built on 9 June 2015
Class: Elevation of Privilege

Summary:
The Malicious Software Removal Tool executable uses the global temp directory to write and load some DLLs. By exploiting a race condition in this it’s possible to get a DLL loaded into MRT.exe running at Local System causing elevation of privilege.

Description:

The Malicious Software Removal Tool is distributed as the monolithic executable MRT.exe. When this executes it writes three DLLs to c:\windows\temp directory then loads them using LoadLibraryEx. As a normal user can write to c:\windows\temp it’s possible to exploit a race condition in the process to replace one the DLLs after the MRT executable has verified the files signature but before LoadLibraryEx is called. While MRT.exe seems to sort of try and protect itself by holding a handle to these 3 DLLs it only specifies a READ/DELETE lock (which is necessary for things like LoadLibrary to work) which means we can rename a DLL during the operation, freeing up the directory entry so we can replace the file. 

We can exploit it by using a sequence of oplocks to trap the major steps of the file creation. Currently we can do something like this:

1. Create dummy files for the 3 DLL in the temp folder so that the user can write to them, we can now start MRT through its scheduled task or just wait for it to start at some defined interval. 
2. Oplock on DEVINV.DLL, once this triggers MPENGINE.DLL and MPGEAR.DLL has been dropped to the temp folder by MRT.exe
3. Oplock on MPGEAR.DLL, this is just to pass the writing of DEVINV.DLL. 
4. Oplock on DEVINV.DLL again. Once this triggers it means that MPGEAR.DLL and MPENGINE.DLL have been opened and read into memory (not sure why MRT does this, perhaps it’s verifying it wrote them correctly)
5. We can now move MPENGINE.DLL out of the way by renaming it, we then recopy the same DLL to a new copy in the temp folder.
6. We oplock on MPENGINE.DLL, once this triggers MRT is just about to verify the signature in WinVerifyTrust. 
7. The last step is the only one which requires brute force, we spin in a loop trying to open the file for write access (remember that the MPENGINE.DLL file opened by WinVerifyTrust isn’t the same one opened between steps 3 and 4, so when the handle is closed we can open with exclusive access). To ensure LoadLibrary doesn’t get a sharing violation while we’re overwriting the DLL we use the native create option FILE_OPEN_REQUIRING_OPLOCK to atomically open the file and set a preliminary oplock. We never finish the oplock but it doesn’t matter for our purposes. Choosing MPENGINE is the most reliable because it’s very large so takes a long time in WinVerifyTrust. 
8. Once we close the file handle we’ll release the oplock, LoadLibraryEx will now load our malicious DLL and we get system privileges.

There are a couple of problems with the exploit/vulnerability. Firstly I’ve seen some versions of MRT leave the DLLs in the directory, this causes a problem as a normal user cannot replace them. However the versions I’m looking at now seems to delete the files after use so you can plant the appropriate files. Second there seems to be some condition where MRT creates a randomly named directory and instead drops the files there, that seems to be the “correct” solution but it isn’t clear under what conditions it happens. Finally in order to get MRT to run you can execute a scheduled task but a normal user cannot do that, instead they’d have to wait around for the computer to become idle to trigger the task. 

Basically I don’t think MRT should be using Windows Temp at all, but if it does it should at least create random names. Another thing I’ve noticed is that, at least for a machine and a particular version of MRT it creates a known directory in temp and writes scan results to it. This might be exploitable in some way using junctions etc to overwrite files. I’ve not tested this.

Proof of Concept:

The PoC demonstrates the vulnerability getting cmd running at system privileges on the current active desktop. Note for simplicity the scheduled task needs to be started by an administrator, but in theory you could leave it running until the scheduled task runs on its own. The password for the 7z file is ‘password’. 

1) Extract the PoC to a location on the system hard disk (where Windows is) and is writable by a normal user
2) As a normal user execute MrtTest.exe, it stop wait.
3) Execute the scheduled task using an administrator copy of powershell with the command Start-ScheduledTask \Microsoft\Windows\RemoveTools\MRT_HB
3) The PoC should print the current steps

Troubleshooting:

If the poc exits immediately it’s likely that it can write the DLLs to the temp folder. If you want to verify it works delete the DLLs from an administrator’s account. Not sure what conditions they’ll stay there, perhaps it’s an old version thing? 

If it starts but nothing happens perhaps MRT has decided to use the random directory name instead.

Expected Result:
It shouldn’t be possible to replace the DLLs files or even get access to the location

Observed Result:
CMD is running as system due to the malicious DLL being loaded by MRT.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.


 
poc.7z
95.4 KB Download
Project Member

Comment 1 by forshaw@google.com, Jun 11 2015

Labels: Id-30421
Received MSRC Case Number 30421
Project Member

Comment 2 by forshaw@google.com, Jun 23 2015

Correspondence Date: 23 Jun 2015
> Microsoft says they've managed to reproduce and will determine whether it's something which needs to be fixed in a security bulletin. 
Project Member

Comment 3 by forshaw@google.com, Jul 10 2015

Labels: CVE-2015-2418
Microsoft have assigned a CVE and expect to fix the issue in the upcoming patch tuesday.
Project Member

Comment 4 by forshaw@google.com, Jul 14 2015

Project Member

Comment 5 by forshaw@google.com, Jul 22 2015

Labels: -Restrict-View-Commit
Opening issue

Sign in to add a comment