Create a new version of paste:

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.