Google vs Microsoft; Google Research Team Make Two More Windows 7/8 Vulnerabilities Public

The Google vs Microsoft war hots up as Google reveals two more Windows 7 and Windows 8 vulnerabilities.

The Google Research Team has put two more unpatched Windows vulnerabilities in public domain on Thursday after the expiration of Google Project Zero’s self-imposed 90-day waiting period before disclosing bug details.

Microsoft which has not taken kindly to these kind of public disclosures has said that it will patch one of the two vulnerabilities in its upcoming February Patch Tuesday security bulletin release. The second flaw it seems is not a big security issue.

Readers may remember that the Google research team had made a privilege escalation vulnerability in Windows 7 public after expiration of the self imposed 90 day waiting period.  Google’s disclosure on Dec 29 revived disclosure debates between security enthusiasts and ignited acrimony and public posturing from both the companies.

Microsoft wants Google to follow a coordinated vulnerability disclosure program and had asked Google to withhold its disclosure of the vulnerability until the January security bulletins, which were released this week. Google on the other hand relies on its self imposed 90 day moratorium so it refused and went ahead with its disclosure.

Microsoft’s Chris Betz has stated that, “Although following through keeps to Google’s announced timeline for disclosure, the decision feels less like principles and more like a ‘gotcha’, with customers the ones who may suffer as a result.  What’s right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal.”

The war between the tech giants is far from over as Google research team has made two more Windows vulnerabilities public. Both the vulnerabilities are reproduced below :

Issue No. 127 reported to Microsoft on 17th October, 2013 made public on 15th Jan, 2014

Platform: Windows 7 32/64 bit, Windows 8+ not vulnerable
Class: Security Bypass

The system call NtPowerInformation performs a check that the caller is an administrator before performing some specific power functions. The check is done in the PopUserIsAdmin function. The rough implementation is:

BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx;

SeCaptureSecurityContext(&ctx);

return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
}

On Windows 7 this check is bypassable because the SeTokenIsAdmin function doesn’t take into account the impersonation level of the token and the rest of the code also doesn’t take it into account. Therefore you can impersonate an administrator’s token as a normal user (through linked token or kidnapping a system token) and call the protected functions. On Windows 8+ the SeTokenIsAdmin method has been changed to check for the impersonation level so it’s not vulnerable.

It isn’t clear if this has a serious security impact or not, therefore it’s being disclosed as is. Some functions are also checked by a privilege check, however the subject context is captured separately so there exists a TOCTOU window between checks which could be exploited. For PoC purposes I’ve chosen to use function 45 “PopRequestPowerListInfo” (which doesn’t require any special tricks. Also this function has a theoretical integer overflow vulnerability depending on how much you can push the size of PopPowerRequestObjectCount.

Attached is a simple PoC which demonstrates the issue for execution on Windows 7. To reproduce follow the steps.

1) Ensure running as a split token administrator, this is because the PoC uses the linked token to get an administrator token. For a normal user you could just capture a token from a service.
2) Execute the PoC, it should do calls, one without impersonation and one with.

Expected Result:
Both calls should return STATUS_ACCESS_DENIED (0xC0000022)

Observed Result:
First check fails with STATUS_ACCESS_DENIED while second succeeds with STATUS_SUCCESS.

PoC for download => 1 2

Issue No.128 reported to Microsoft on 17th October, 2013 made public on 15th Jan, 2014

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

PoC download => Zip File

Microsoft will patch only one of the vulnerabilities in its February Patch Tuesday which it said that the other vulnerability is not a security risk.  Both Microsoft and Google said that they have no proof of any of the three vulnerabilities made public, had been exploited in the wild.