Google's Project Zero reveals security flaw in Windows 10 S after Microsoft fails to fix it

Details of a security flaw in Windows 10 S have been revealed by Google's Project Zero after Microsoft failed to issue a patch within the 90-day disclosure deadline.

The "WLDP CLSID policy .NET COM Instantiation UMCI Bypass" vulnerability is described as being of medium severity, and it allows for the execution of arbitrary code on systems with Device Guard enabled.

See also:

• Microsoft reveals more about the 'blocking bug' that is delaying Windows 10 Spring Creators Update
• It looks like there will be a new RTM build of Windows 10 as build 17134 is discovered
• Microsoft discovers blocking bug and delays the release of Windows 10 Spring Creators Update

That the problem affects Windows 10 S is something of an embarrassment for Microsoft; this particular version of its operating system is pitched as being "streamlined for security and superior performance".

It was initially reported to Microsoft back in January, and after indicating that it would not -- or could not -- be fixed in April's Patch Tuesday, Microsoft asked for a 14-day extension, but this was denied. The company asked once again for an extension, noting that Redstone 4 will fix the issue, but Project Zero pointed out that this "wouldn't be considered a broadly available patch per the disclosure conditions", hence the disclosure.

The Project Zero entry for the security flaw explains the problem:

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 (https://github.com/tyranid/DotNetToJScript).

A proof of concept is available, but there are mitigating factors. As the discoverer -- a user called Forshaw -- explains: "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".

Image credit: Artem Postoev / Shutterstock