On November 12, 2020, security researcher Clément Labro published a detailed analysis of a local privilege escalation vulnerability affecting Windows 7 and Windows Server 2008 R2 for which no official fix exists yet (at the time of this writing). Although these Windows platforms have reached end of support in January this year but Extended Security Updates (ESU) are still available for them until January 2023 - so even fully ESU-updated machines are currently affected by this issue.
As an alternative to ESU, we at 0patch have "security adopted" Windows 7 and Windows Server 2008 R2 and are providing critical security patches for these platforms. Consequently, vulnerabilities like this one get our attention - and, usually, micropatches.
Clément wrote a very useful permissions-checking tool for Windows that find various misconfigurations in Windows that could allow a local attacker to elevate their privileges. On a typical Windows 7 and Server 2008 R2 machine, the tool found that all local users have write permissions on two registry keys:
These didn't immediately seem exploitable, but Clément did the legwork and found the Windows Performance Monitoring mechanism can be made to read from these keys - and eventually load the DLL provided by the local attacker. To most everyone's surprise, not as the local user, but as Local System.
In short, a local non-admin user on the computer just creates a Performance subkey in one of the above keys, populates it with some values, and triggers performance monitoring, which leads to a Local System WmiPrvSE.exe process loading attacker's DLL and executing code from it.
Now this is clearly a case of incorrect permissions on the above registry keys, and the solution should be obvious - correcting these permissions. However, we don't want our micropatches to make any global changes to the system, so we decided to address this in the code.
We analyzed where the Performance registry key is being read in Windows libraries and found that to be in advapi32.dll, function OpenExtensibleObjects, as a result of a call to RegKeyOpen* function with one of the performance-related predefined keys, in our case HKEY_PERFORMANCE_DATA.
Function OpenExtensibleObjects iterates through all services in the registry looking for Performance keys, and we decided to patch it so that it would ignore this key in both affected services - making it look as if the Performance key wasn't there even if it was.
This obviously breaks performance monitoring for the affected services but that's a trade-off we believe is beneficial to our users. In case performance monitoring is needed for these services, the micropatch can always be temporarily disabled (again, no restart of the service, much less of the computer, is needed for that).
|Source code of the micropatch|
The video below shows how the attack works on a Windows 7 computer exploiting bad permissions on the Dnscache registry key. An identical attack could be mounted using the RpcEptMapper key.
- Windows 7 and Server 2008 R2 computers without ESU, updated to January 2020, and
- Windows 7 and Server 2008 R2 computers with ESU, updated to November 2020,
- [Updated 1/22/2021] Windows 7 and Server 2008 R2 computers with ESU, updated to December 2020 or January 2021