Microsoft Trusted Boot Security Feature Bypass
Posted on 15 October 2015
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.
