While Microsoft was not done criticizing Google for publishing Windows 8 vulnerabilities, Google looks in no mood to stop these disclosures. In fact, it has now published two more Windows 7 and Windows 8 vulnerabilities at a global scale that it found while examining the operating systems under its ‘peace mission’, a.k.a. Project Zero.
Out of the two bugs, one will find meet its end in the upcoming February Patch. As for the other one, Microsoft seems to be completely okay and is not considering it as a big security issue. The links to the vulnerabilities is this. You can find the entire Google issued notice towards the end of this post.
One of the bugs, termed issue No. 128, allows potential hackers to impersonate the victim and further decrypt or encrypt the data being transferred between the current logged in session.
If this is the first time you’ve heard of Google’s Project Zero and how it has exposed Microsoft bugs, here’s a flashback:
Earlier this month, Google published a Windows 8.1 vulnerability that allows lower-level users on Windows 8.1 systems to make themselves system administrators, hence, gaining access to the server settings and other top level privileges.
The whole act of publishing the vulnerabilities was carried out the under the shadow of “Project Zero“. The initiative led by Google tracks software flaws, conducts an in-depth research and eventually informs the software developer about possible ways that the bug can be exploited. Google provides a time period of 90 days to fix the problems before Project Zero publishes the bug along with the code.
Since Microsoft failed to fix the problem within the specified deadline, Google went against the Redmond giant and published the bug publicly. No doubt, this act deeply offended Microsoft and was soon followed by a shower of unpleasant words.
Microsoft expressed its discontent via a post saying that it notified Google about the developed fix which was to be bundled with the next update. Microsoft further claimed that it also informed about the release date of the update, which was just two day post the publish of the bug.
Microsoft further criticized Google’s approach of making the bug known publicly and said that it could have found a better way to inform users so that they can make preparations against the threat. “What’s right for Google is not always right for customers,” well, that pretty much tells us how agitated the software giant is.
Google’s recent stride of publishing two more articles is indeed a firm reply to the criticism it received. This is the third time that the Redmond giant has been ‘trolled’ by Google. A similar vulnerability in Windows 8.1 was earlier published by Google in September, before Microsoft could publish a fix.
Well, one can only imagine the agitation that Google has conceived in the Microsoft department. Though, Microsoft has said that it will soon fix the vulnerabilities, it has not expressed its annoyance yet. You may expect that soon.
Here’s the Google notice in its entirety :
Platform: Windows 7, 8.1 Update 32/64 bit Class: Security Bypass/Information Disclosure The function CryptProtectMemory allows an application to encrypt memory for one of three 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 identifier, 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. Attached is a simple PoC which demonstrates the issue. To reproduce follow the steps. 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. Expected Result: Both calls should return the same encrypt data, or the second call should fail Observed Result: 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.