Windows: RegLoadAppKey Hive Enumeration EoP
Platform: Windows 10 10586 not tested 8.1 Update 2 or Windows 7
Class: Elevation of Privilege
Summary:
RegLoadAppKey is documented to load keys in a location which can’t be enumerated and also non-guessable. However it’s possible to enumerate loaded hives and find ones which can be written to which might lead to EoP.
Description:
The RegLoadAppKey API loads a user specified hive without requiring administrator privileges. This is used to provide per-application registry hives and is used extensively by Immersive Applications but also some system services. The MSDN documentation states that the keys cannot be enumerated, the only way to get access to the same hive is by opening the file again using RegLoadAppKey which requires having suitable permissions on the target hive file. It also ensures that you can’t guess the loaded key name by generating a random GUID which is going to be pretty difficult to brute-force.
This in part seems to be true if you try and open directly the attachment point of ‘\Registry\A’. That fails with access denied (I’ve not looked into the kernel to work out what actually does this check). However there’s no protection from recursive enumeration, so we can open ‘\Registry’ for read access, then open ‘A’ relative to that key. With this we can now enumerate all the loaded per-app hives.
What we can do with this is less clear cut as it depends on what is using application hives at the current point in time. Immersive applications use per-app hives for their activation data and settings. While the activation hive seems to be correctly locked to only the user, the settings are not. As the default DACL for the settings hive is granting Everyone and ALL_APPLICATION_PACKAGES full access this means an Immersive Application could read/write settings data from any other running application. This even works between users on the same machine, so for example on a Terminal Server one user could read the settings of another user’s running Immersive Applications. At the least this is an information disclosure issue, but it might Edge content processes to access the settings of the main Edge process (which runs under a different package SID).
A few system services also use per-app hives, including the Background Tasks Infrastructure Service and Program Compatibility Assistant. The tasks hive is locked for write access to normal user’s although it can be read, while the PCA hive is fully writable by any user on the system (the hives file isn’t even readable by a normal user, let alone writable). I’ve not investigated if it’s possible to abuse this access to elevate privileges, but it certainly seems a possibility. There might be other vulnerable services which could be exploited, however I’ve not investigated much further on this.
In the end it’s clear that there’s an assumption being made that as these hives shouldn’t be enumerable then that’s enough security to prevent abuse. This is especially true with the settings hives for immersive applications, the file DACL is locked to the package SID however the hive itself is allowed for all access to any package and relies on the fact that an application couldn’t open a new handle to it as the security boundary.
Proof of Concept:
I’ve provided a PoC as a C# source code file. You need to compile it first.
1) Compile the C# source code file.
2) Execute the PoC executable as a normal user.
3) The PoC should print that it’s found some registry hives which it shouldn’t be able to enumerate.
4) It should also say it’s found the PCA hive as well.
Expected Result:
You can’t enumerate per-app registry hives.
Observed Result:
The hives can be enumerated and also some of them can be written to.
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.
