Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement