New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Mar 2015
Cc:



Sign in to add a comment
Windows: Registry Virtualization TOCTOU User Check
Project Member Reported by forshaw@google.com, Dec 9 2014 Back to list
Windows: Registry Virtualization TOCTOU User Check
Platform: Windows 8.1 Update (Windows 7 not vulnerable)
Class: Security Bypass

Summary:
There exists a TOCTOU issue in the handling of registry virtualization which allows one user to cause a write into the VirtualStore for another logged on user. 

Description:
When the virtualization flag is set on the primary token certain parts of the HKLM\Software hive are virtualized to a per-user location under Software\Classes. If the key exists in HKLM (and can be virtualized) then a handle to the HKLM key is opened read-only and the virtualized key is only created if any modification is made to the key, such as writing a value. 

The issue is that during the initialization of system calls such as NtSetValueKey a call is made to CmpIsSystemEntity which will only succeed if the thread is not impersonating and the primary token is virtualized. The call to get the user identity for the location of the virtualized hive, CmpGetVirtualizationID calls PsReferenceEffectiveToken which will pick up the impersonation token if any. As that code also doesn't check that the token is at Impersonation level or above it will happily lookup the associated SID. There exists a race condition between the initial CmpIsSystemEntity call and any subsequent CmpGetVirtualizationID calls. If this can be exploited the VirtualStore entry will be created by the kernel with no security checks. 

For this to work the target user must be logged in so their classes hive is loaded. There's no need to steal a token as S4U will happily provide an identification token on demand. 

Proof of Concept:

Provided is a PoC which tests this issue. It MUST be run on a multi-processor system otherwise it's difficult to exploit the race condition. To execute follow these steps:

1) Create two users on the system, say user1 and user2.
2) Log in both users using fast-user switching so that both their classes hives are loaded at the same time
3) Execute the PoC from one user passing it the name of the other
4) Once it completes observer that the VirtualStore of the other user contains an entry for SOFTWARE\Microsoft with a test value in it. 

Expected Result:
The set value call should write to the current user's VirtualStore

Observed Result:
The set value call writes to the other logged on user's VirtualStore

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.zip
47.1 KB Download
Project Member Comment 1 by forshaw@google.com, Dec 10 2014
Labels: MSRC-21173
Project Member Comment 2 by forshaw@google.com, Jan 14 2015
Correspondance Date: 19 Dec 2014

> Microsoft indicate that they've had difficulty reproducing it from the PoC, stating that the detailed write-up was not included in the original report. They ask for further details

< The original write-up is sent to Microsoft as it seems that the details might not have been provided originally. 
Project Member Comment 3 by forshaw@google.com, Jan 14 2015
Correspondance Date: 14 Jan 2015

< Informed Microsoft that we're willing to extend the deadline 9 days in this situation because we had apparently not provided a writeup. This corresponds with the time it took for them to get back to us informing us of the mistake. Requested that they in future inform us immediately if such information is missing as it should be expected that we would provide these details in order to maximize the chances of remediation of the issue for user security. Requested confirmation of this offer.
Project Member Comment 4 by forshaw@google.com, Jan 16 2015
Labels: -Reported-2014-Dec-09 Reported-2014-Dec-18
Updating reported date to reflect adjusted timescales as requested by Microsoft
Project Member Comment 5 by forshaw@google.com, Feb 10 2015
Correspondence Date: 10 Feb 2015:

> Microsoft indicate that the patch is currently expected to be released in March
Project Member Comment 6 by forshaw@google.com, Mar 10 2015
Labels: CVE-2015-0073 MS15-025
Fixed in bulletin https://technet.microsoft.com/library/security/MS15-025
Project Member Comment 7 by forshaw@google.com, Mar 10 2015
Status: Fixed
Project Member Comment 8 by forshaw@google.com, Mar 17 2015
Labels: -Restrict-View-Commit
Sign in to add a comment