search

v4ng3l1s / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows: Registry Virtualization TOCTOU User Check #215

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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.

Original issue reported on code.google.com by fors...@google.com on 9 Dec 2014 at 4:29

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 10 Dec 2014 at 9:03

GoogleCodeExporter commented 9 years ago 
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.

Original comment by fors...@google.com on 14 Jan 2015 at 11:17

GoogleCodeExporter commented 9 years ago 
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.

Original comment by fors...@google.com on 14 Jan 2015 at 11:18

GoogleCodeExporter commented 9 years ago 
Updating reported date to reflect adjusted timescales as requested by Microsoft

Original comment by fors...@google.com on 16 Jan 2015 at 1:16

GoogleCodeExporter commented 9 years ago 
Correspondence Date: 10 Feb 2015:

> Microsoft indicate that the patch is currently expected to be released in 
March

Original comment by fors...@google.com on 10 Feb 2015 at 6:51

GoogleCodeExporter commented 9 years ago 
Fixed in bulletin https://technet.microsoft.com/library/security/MS15-025

Original comment by fors...@google.com on 10 Mar 2015 at 7:08

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 10 Mar 2015 at 7:10

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 17 Mar 2015 at 2:07