The flaw aims users with user mode code integrity (UMCI) and Device Guard enabled, which Windows 10 S has by default, says Project Zero. This vulnerability allows an attacker to run arbitrary code to jailbreak Windows 10 S, which is basically designed for “streamlined for security and superior performance.” For those unfamiliar, Project Zero is a team of security analysts employed by Google to find zero-day vulnerabilities before they are found and exploited by malicious people. On finding and disclosing the vulnerability to the relevant company, Google gives them 90 days to fix the issue. However, if the company fails to issue a patch within the specified time period, the Project Zero team discloses the vulnerability to the public so that users can protect themselves by taking necessary steps. According to the researchers, the vulnerability arises from how Windows 10 S validates the identity of high-privilege components. Explaining the security flaw, the Project Zero entry reads: The WLDP COM Class lockdown policy contains a hardcoded list of 8 to 50 COM objects which enlightened scripting engines can instantiate. Excluding issues related to the looking up of the correct CLSID (such as previously reported abuse of TreatAs case 40189). This shouldn’t be a major issue even if you can write to the registry to register an existing DLL under one of the allowed COM CLSIDs as a well behaved COM implementation should compare the CLSID passed to DllGetObject against its internal list of known objects. Turns out .NET is not one of these well behaved COM implementations. When a .NET COM object is instantiated the CLSID passed to mscoree’s DllGetClassObject is only used to look up the registration information in HKCR. At this point, at least based on testing, the CLSID is thrown away and the .NET object created. This has a direct impact on the class policy as it allows an attacker to add registry keys (including to HKCU) that would load an arbitrary COM visible class under one of the allowed CLSIDs. As .NET then doesn’t care about whether the .NET Type has that specific GUID you can use this to bootstrap arbitrary code execution by abusing something like DotNetToJScript. According to the bug report issued by researcher James Forshaw, the medium-severity bug could allow an attacker to add register keys that “would load an arbitrary COM visible class under one of the allowed CLSIDs.” Forshaw says, “It’s not an issue which can be exploited remotely, nor is it a privilege escalation. An attacker would have to already have code running on the machine to install the registry entries necessary to exploit this issue, although this could be through an RCE such as a vulnerability in Edge.” However, he adds, “There’s at least two known DG bypasses in the .NET framework that are not fixed, and are still usable even on Windows 10 S so this issue isn’t as serious as it might have been if all known avenues for bypass were fixed.” According to Project Zero, this is a “medium” security flaw, as the flaw only affects a minority of PCs, but also the hackers would need to physically access the PC. The vulnerability was first reported by Google to Microsoft on January 19 this year. In February, Microsoft confirmed that it would fix the flaw by April’s Patch deadline. However, the company couldn’t complete the fix on April’s Patch Tuesday. Hence, Microsoft asked Google for an extension of two weeks to address the vulnerability in Windows 10, informed Google that a fix will be rolled out in the May Patch Tuesday. Since, this extension period exceeded the grace deadline as well, Google denied Microsoft’s request for an additional 14-day grace period and went ahead and made the flaw public that mainly affects Windows 10 S. With Google making the flaw public, it will be interesting to see if Microsoft is able to roll out the fix Patch on May Patch Tuesday as confirmed to Google earlier.
