Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 1 user
Status: Fixed
Owner:
Closed: Sep 2016
Cc:



Sign in to add a comment
Windows: NtLoadKeyEx User Hive Attachment Point EoP
Project Member Reported by forshaw@google.com, Jun 29 2016 Back to list
Windows: NtLoadKeyEx User Hive Attachment Point EoP
Platform: Windows 10 10586 (32/64) and 8.1 Update 2, not tested Windows 7
Class: Elevation of Privilege

Summary:
The NtLoadKeyEx system call allows an unprivileged user to load registry hives outside of the \Registry\A hidden attachment point which can be used to elevate privileges. 

Description:

Windows Vista and above support loading per-user registry hives. Normally calling NtLoadKeyEx would require Backup/Restore privileges to do this making it useless for the average user.. However per-user hives are permitted from a normal user. When calling the Win32 API RegLoadAppKey the hive is loaded under \Registry\A which is a hidden attachment key and doesn’t provide any obvious benefit from an EoP perspective (especially as the root name is a random GUID). However it turns out that you can load the per-user hive to any attachment point such as \Registry\User or \Registry\Machine. Interestingly this works even as a sandboxed user, so it would be an escape out of EPM/Edge/Bits of Chrome etc.

So how can we exploit this? The simplest way I’ve found is to register the hive as the local system "Classes" key. This isn’t registered by default, however a quick inspection indicates that local system does indeed refer to this key when trying to access COM registration information. So by putting an appropriate registration in \Registry\User\S-1-5-18_Classes it will be loaded as a local system component and privileged execution is achieved.

Proof of Concept:

I’ve provided a PoC as a C# source code file. You need to compile it first. It uses the issue with NtLoadKeyEx to map a custom hive over the local system’s Classes key. It then registers a type library which is loaded when WinLogon is signaled. I signal WinLogon by locking the screen. It abuses the fact that registered type library paths when passed to LoadTypeLib can be a COM moniker. So I register a COM scriptlet moniker which will be bound when LoadTypeLib parses it, this causes a local scriptlet file to be executed which respawns the original binary to spawn an interactive command prompt. By doing it this way it works on 32 bit and 64 bit without any changes.

Note that it doesn’t need to use the Lock Screen, just this was the first technique I found. Many system services are loading data out of the registry hive, it would just be a case of finding something which could be trivially triggered by the application. In any case imo the bug is the behaviour of NtLoadKeyEx, not how I exploit it.

1) Compile the C# source code file.
2) Execute the PoC executable as a normal user.
3) The PoC should lock the screen. You’ll need to unlock again (do not log out).
4) If successful a system level command prompt should be available on the user’s desktop when you unlock.

Expected Result:
You can’t create a per-user hive outside of the hidden attachment point.

Observed Result:
Well obviously you can.

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.

 
Program.cs
13.5 KB View Download
Project Member Comment 1 by forshaw@google.com, Jun 29 2016
Labels: MSRC-34012
Project Member Comment 2 by forshaw@google.com, Sep 23 2016
Labels: -Restrict-View-Commit -Severity-High Severity-HIgh CVE-2016-3371
Status: Fixed
Fixed in https://technet.microsoft.com/library/security/MS16-111
Comment 3 Deleted
Sign in to add a comment