Nytro Posted October 15, 2015 Report Posted October 15, 2015 Vulnerability title (Microsoft): Trusted Boot Security Feature Bypass VulnerabilityCVE: CVE-2015-2552Vendor: MicrosoftProduct: 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 SecureBoot 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 correctlyprotect against attempts to enable features that are prohibited while UEFISecure Boot is enabled, such as "test-signing" and the local kerneldebugger. 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 aregistry hive used by the operating system boot loader to load and preparethe NT kernel (ntoskrnl.exe) for launch. In UEFI systems, this task issplit between bootmgr.efi and winload.efi. The latter is what contains thisvulnerability.One of winload.efi's responsibilities is to take the settings in BCD andtranslate them to a simple command line for the kernel, similarly to Linux.When an attempt to enable a prohibited feature such as "test-signing" occursthe 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 commandline arguments to the NT kernel. An obvious attack would be to attempt topass "/TESTSIGNING" by putting it into the "loadoptions" field. winload.eficounters this obvious attack by checking against a blacklist of strings, butfails to account for Unicode.BCD, being a registry hive, stores all strings as UTF-16. To search for theprohibited strings, winload.efi calls wcsstr(). However, ntoskrnl.exe takesits command line as ASCII bytes. To do the conversion from Unicode toASCII, winload.efi simply truncates each UTF-16 code point to 8 bits.The bug is then simple: winload.efi is checking against pre-transformeddata, while ntoskrnl.exe is checking post-transformed data. By replacingcharacter(s) of a blacklisted string with Unicode characters that become theoriginal character(s) when truncated to 8 bits, one can get past thewcsstr() check while still passing the desired parameter to the kernel.Proof of Concept:================In an Administrator-privileged instance of PowerShell, execute thefollowing command, then reboot:bcdedit /set '{current}' loadoptions '/T_STSIGNING'replacing "_" with the Unicode character U+0145 ("Latin Capital Letter NWith 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 tokernel privilege by loading unsigned drivers, or using the kernel debuggerto poke at kernel memory and gain arbitrary code execution.Users can intentionally use this on their own devices to bypass lockdownsfor 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 theexploit is known.Systems affected:================UEFI systems with Secure Boot enabled running the following:Windows 8Windows 8.1Windows Server 2012Windows Server 2012 R2Windows 10Windows Server 2016 Technical PreviewWindows RT 8.0Windows RT 8.1Windows Phone 8Windows Phone 8.1Windows Mobile 10 PreviewAdvisory:========https://technet.microsoft.com/en-us/library/security/ms15-111.aspxSolution:========Install KB3088195.https://support.microsoft.com/en-us/kb/3096447(mismatched number intentional)Disclosure Timeline:===================Discovery: Approximately summer 2013Vendor notification: Unknown Vendor fixed vulnerability: October 13, 2015Public advisory: October 13, 2015Public disclosure: October 13, 2015 The author, the original discoverer, did not report it. The authorbelieves that the disclosure happened in approximately spring 2015.Sursa: [CVE-2015-2552] Windows 8+ - Trusted Boot Bypass - Pastebin.com Quote