New issue
Advanced search Search tips
Starred by 8 users
Status: WontFix
Owner:
Closed: Jan 2015
Cc:



Sign in to add a comment
Windows 7: Admin Check Bypass in NtPowerInformation
Project Member Reported by forshaw@google.com, Oct 17 2014 Back to list
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.

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.

 
Poc_NtPowerInformation_AdminBypass.cpp
1.0 KB Download
Poc_NtPowerInformation_AdminBypass.exe
13.5 KB Download
Project Member Comment 1 by forshaw@google.com, Oct 17 2014
Labels: MSRC-20706
Project Member Comment 2 by forshaw@google.com, Nov 28 2014
Owner: forshaw@google.com
Project Member Comment 3 by forshaw@google.com, Dec 2 2014
Labels: -Product-Windows Product-Windows-Kernel
Project Member Comment 4 by forshaw@google.com, Jan 13 2015
Correspondance Date: 29 Oct 2014

> Microsoft say they've reproduced the issue on Windows 7 (8+ is not vulnerable as expected) and to quote, "it seems to max out as a Medium IL to High IL elevation which doesn't immediately align with bulletin servicing in that Medium to High isn't a defined security boundary"

< Responded with informing Microsoft that we don't believe it's a UAC issue (which is a typical way of describing IL related elevation issues), the use of the linked token is a PoC implementation issue, it's possible to steal an administrator level token through other means (such as BITS) while running as a normal user. The code is clearly incorrectly checking the current impersonation token for administrator privileges which constitutes a defined security boundary. Provided a link to a forum post on OSR (http://www.osronline.com/showthread.cfm?link=201029) where their own Ken Johnson provides caution for this exact security issue. That said it's conceded that there's no obvious serious security implication associated with the bypass of the check. 
Project Member Comment 5 by forshaw@google.com, Jan 14 2015
Correspondance Date: 14 Jan 2015

< Asked Microsoft if they believe this issue is not going to be fixed and if so whether we can make it as won't fix and remove the view restriction.
Project Member Comment 6 by forshaw@google.com, Jan 15 2015
Labels: -Restrict-View-Commit PublicOn-2015-Jan-15
Status: WontFix
Correspondance Date: 14 Jan 2015

> Microsoft have stated that this issue is not considered serious enough for a bulletin release as it only allows limited information disclosure about power settings. It will be under consideration for fixing in future versions of Windows.

We agree with this assessment and will remove the view restriction on the issue.
Comment 7 Deleted
Rebase_all_Google_Microsoft_gmail_github

Project Member Comment 9 by forshaw@google.com, Mar 12 2015
Correspondence Date: 10 Mar 2015

< Asked Microsoft if CVE-2015-0075 in MS15-025 fixed SeTokenIsAdmin downlevel as that would make this issue fixed.
Was there ever any response back from Microsoft?
Is this still an issue, say, with Windows10 - It may seem trivial, but the ability to affect power settings includes the ability to enforce frequent and RAM-heavy 'hibernation' which can cause corruption and severely impact a workstation
https://00000000%/google.com
Sign in to add a comment