|
|
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.
Project Member
Comment 1
by
forshaw@google.com,
Oct 17 2014
,
Nov 28 2014
,
Dec 2 2014
,
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.
,
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.
,
Jan 15 2015
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.
,
Feb 27 2015
Rebase_all_Google_Microsoft_gmail_github
,
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.
,
Aug 18 2015
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
,
Nov 16 2015
https://00000000%/google.com |
|||||
| ► Sign in to add a comment | |||||