MS16-124 CVE-2016-0079 Windows – NtLoadKeyEx Privilege Escalation

Windows - NtLoadKeyEx Read Only Hive Arbitrary File Write Privilege Escalation (MS16-124)

Windows: NtLoadKeyEx Read Only Hive Arbitrary File Write EoP
Platform: Windows 10 10586 not tested 8.1 Update 2 or Windows 7
Class: Elevation of Privilege
NtLoadKeyEx takes a flag to open a registry hive read only, if one of the hive files cannot be opened for read access it will revert to write mode and also impersonate the calling process. This can leading to EoP if a user controlled hive is opened in a system service.
One of the flags to NtLoadKeyEx is to open a registry hive with read only access. When this flag is passed the main hive file is opened for Read only, and no log files are opened or created. However there’s a bug in the kernel function CmpCmdHiveOpen, initially it calls CmpInitHiveFromFile passing flag 1 in the second parameter which means open read-only. However if this fails with a number of error codes, including STATUS_ACCESS_DENIED it will recall the initialization function while impersonating the calling process, but it forgets to pass the read only flag. This means if the initial access fails, it will instead open the hive in write mode which will create the log files etc.
An example where this is used is in the WinRT COM activation routines of RPCSS. The GetPrivateHiveKeyFromPackageFullName method explicitly calls NtLoadKeyEx with the read only flag (rather than calling RegLoadAppKey which will not). As this is opening a user ActivationStore.dat hive inside the AppData\Local\Packages directory in the user’s profile it’s possible to play tricks with symbolic links to cause the opening of the hive inside the DCOM service to fail as the normal user then write the log files out as SYSTEM (as it calls RtlImpersonateSelfEx).
This is made all the worse because of the behaviour of the file creation routines. When the log files are being created the kernel copies the DACL from the main hive file to the new log files. This means that although we don’t really control the log file contents we can redirect the write to an arbitrary location (and using symlink tricks ensure the name is suitable) then reopen the file as it has an explicit DACL copied from the main hive we control and we can change the file’s contents to whatever you like.
Proof of Concept:
I’ve provided a PoC as a C# source code file. You need to compile it first targetted .NET 4 and above. I’ve verified you can exploit RPCSS manually, however without substantial RE it wouldn’t be a very reliable PoC, so instead I’ve just provided an example file you can fun as a normal user. This will impersonate the anonymous token while opening the hive (which in reality would be DACL’ed to block the user from opening for read access) and we verify that the log files are created.
1) Compile the C# source code file.
2) Execute the PoC executable as a normal user.
3) The PoC should print that it successfully opened the hive in write mode.
Expected Result:
The hive fails to open, or at least only opens in read-only mode.
Observed Result:
The hive is opened in write mode incorrectly which can be abused to elevate privileges.