Windows 7: Admin Check Bypass in NtPowerInformation

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by fors...@google.com on 17 Oct 2014 at 10:22

Attachments:

• Poc_NtPowerInformation_AdminBypass.cpp
• Poc_NtPowerInformation_AdminBypass.exe

[GoogleCodeExporter]

Original comment by fors...@google.com on 17 Oct 2014 at 9:40

• Added labels: MSRC-20706

[GoogleCodeExporter]

Original comment by fors...@google.com on 28 Nov 2014 at 9:22

[GoogleCodeExporter]

Original comment by fors...@google.com on 2 Dec 2014 at 11:10

• Added labels: Product-Windows-Kernel
• Removed labels: Product-Windows

[GoogleCodeExporter]

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. 

Original comment by fors...@google.com on 13 Jan 2015 at 12:32

[GoogleCodeExporter]

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.

Original comment by fors...@google.com on 14 Jan 2015 at 9:44

[GoogleCodeExporter]

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.

Original comment by fors...@google.com on 15 Jan 2015 at 8:48

• Changed state: WontFix
• Added labels: PublicOn-2015-Jan-15
• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Rebase_all_Google_Microsoft_gmail_github

Original comment by HONEST11...@gmail.com on 27 Feb 2015 at 7:26

[GoogleCodeExporter]

Correspondence Date: 10 Mar 2015

< Asked Microsoft if CVE-2015-0075 in MS15-025 fixed SeTokenIsAdmin downlevel 
as that would make this issue fixed.

Original comment by fors...@google.com on 12 Mar 2015 at 3:46