Google released a “Security Bypass/Information Disclosure” vulnerability that it found in Microsoft’s Windows 7 and 8.1 operating systems.
The CryptProtectMemory function allows an application to encrypt memory for 1 of 3 scenarios, process, logon session and computer. When using the logon session option (CRYPTPROTECTMEMORY_SAME_LOGON flag) the encryption key is generated based on the logon session ID, this is for sharing memory between processes running within the same logon. As this might also be used for sending data from one process to another it supports extracting the logon session id from the impersonation token.
The issue is the implementation in CNG.sys doesn’t check the impersonation level of the token when capturing the logon session id (using SeQueryAuthenticationIdToken) so a normal user can impersonate at Identification level and decrypt or encrypt data for that logon session. This might be an issue if there’s a service which is vulnerable to a named pipe planting attack or is storing encrypted data in a world readable shared memory section.
This behaviour of course might be design, however not having been party to the design it’s hard to tell. The documentation states that the user must impersonate the client, which I read to mean it should be able to act on behalf of the client rather than identify as the client.
1) Execute Poc_CNGLogonSessionImpersonation.exe from the command line
2) The program should print “Encryption doesn’t match” to indicate that the two encryptions of the same data was not a match, implying the key was different between them.
Both calls should return the same encrypt data, or the second call should fail
Both calls succeed and return different encrypted data
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.