Microsoft Trusted Boot Security Feature Bypass

`Vulnerability title (Microsoft): Trusted Boot Security Feature Bypass  
Vulnerability  
CVE: CVE-2015-2552  
Vendor: Microsoft  
Product: Windows NT series 8.0+  
Affected versions: See "systems affected".  
Reported by: "Myria"  
  
Vulnerability Summary:  
=====================  
An attacker with administrative access to a Windows machine with UEFI Secure  
Boot enabled may bypass code signing policy checks by putting intentionally-  
malformed configuration options in the boot configuration database (BCD).  
  
Vulnerability Details:  
=====================  
On a Windows system with Secure Boot enabled, Windows doesn't correctly  
protect against attempts to enable features that are prohibited while UEFI  
Secure Boot is enabled, such as "test-signing" and the local kernel  
debugger. This allows things such as loading unsigned kernel drivers, or,  
in locked-down Windows installations like Windows RT, effect a "jailbreak".  
  
In Windows Vista and later, the boot configuration database ("BCD") is a  
registry hive used by the operating system boot loader to load and prepare  
the NT kernel (ntoskrnl.exe) for launch. In UEFI systems, this task is  
split between bootmgr.efi and winload.efi. The latter is what contains this  
vulnerability.  
  
One of winload.efi's responsibilities is to take the settings in BCD and  
translate them to a simple command line for the kernel, similarly to Linux.  
When an attempt to enable a prohibited feature such as "test-signing" occurs  
the standard way, winload.efi will block the attempt by not passing the  
"/TESTSIGNING" command-line option to the NT kernel.  
  
The BCD setting named "loadoptions" allows passing arbitrary kernel command  
line arguments to the NT kernel. An obvious attack would be to attempt to  
pass "/TESTSIGNING" by putting it into the "loadoptions" field. winload.efi  
counters this obvious attack by checking against a blacklist of strings, but  
fails to account for Unicode.  
  
BCD, being a registry hive, stores all strings as UTF-16. To search for the  
prohibited strings, winload.efi calls wcsstr(). However, ntoskrnl.exe takes  
its command line as ASCII bytes. To do the conversion from Unicode to  
ASCII, winload.efi simply truncates each UTF-16 code point to 8 bits.  
  
The bug is then simple: winload.efi is checking against pre-transformed  
data, while ntoskrnl.exe is checking post-transformed data. By replacing  
character(s) of a blacklisted string with Unicode characters that become the  
original character(s) when truncated to 8 bits, one can get past the  
wcsstr() check while still passing the desired parameter to the kernel.  
  
Proof of Concept:  
================  
In an Administrator-privileged instance of PowerShell, execute the  
following command, then reboot:  
  
bcdedit /set '{current}' loadoptions '/T_STSIGNING'  
  
replacing "_" with the Unicode character U+0145 ("Latin Capital Letter N  
With Cedilla"). The machine will come back up with test-signing enabled,  
which can be seen by the watermark in the lower-right corner of the desktop.  
  
Impact:  
======  
Users or programs with administrative access to a machine can escalate to  
kernel privilege by loading unsigned drivers, or using the kernel debugger  
to poke at kernel memory and gain arbitrary code execution.  
  
Users can intentionally use this on their own devices to bypass lockdowns  
for certain products (Windows Phone, Windows RT).  
  
Mitigating Factors:  
==================  
- The attack requires administrative access.  
- A watermark appears when this is enabled, but this is bypassable.  
  
No public attack against systems for which the owner does not want the  
exploit is known.  
  
Systems affected:  
================  
UEFI systems with Secure Boot enabled running the following:  
  
Windows 8  
Windows 8.1  
Windows Server 2012  
Windows Server 2012 R2  
Windows 10  
Windows Server 2016 Technical Preview  
Windows RT 8.0  
Windows RT 8.1  
Windows Phone 8  
Windows Phone 8.1  
Windows Mobile 10 Preview  
  
Advisory:  
========  
https://technet.microsoft.com/en-us/library/security/ms15-111.aspx  
  
Solution:  
========  
Install KB3088195.  
https://support.microsoft.com/en-us/kb/3096447  
(mismatched number intentional)  
  
Disclosure Timeline:  
===================  
Discovery: Approximately summer 2013  
Vendor notification: Unknown (*)  
Vendor fixed vulnerability: October 13, 2015  
Public advisory: October 13, 2015  
Public disclosure: October 13, 2015  
  
(*) The author, the original discoverer, did not report it. The author  
believes that the disclosure happened in approximately spring 2015.  
`