|
|
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.
Project Member
Comment 1
by
forshaw@google.com,
Dec 10 2014
,
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.
,
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.
,
Jan 16 2015
Updating reported date to reflect adjusted timescales as requested by Microsoft
,
Feb 10 2015
Correspondence Date: 10 Feb 2015: > Microsoft indicate that the patch is currently expected to be released in March
,
Mar 10 2015
Fixed in bulletin https://technet.microsoft.com/library/security/MS15-025
,
Mar 10 2015
,
Mar 17 2015
|
||||||
| ► Sign in to add a comment | ||||||