Using this methodology, Google has disclosed several bugs in the past couple of months, most notably in Windows 10 and Microsoft Edge. Now, the company has revealed a "medium" security flaw in systems with user mode code integrity (UMCI) enabled, and has specifically named Windows 10 S as an example (since it has the policy enabled by default), despite Microsoft's repeated requests for an extension to the disclosure deadline.
Windows 10 S is a highly secure and a somewhat sandboxed operating system developed by Microsoft with many restrictions such as the inability to run Win32 apps. However, Google's Project Zero team has discovered a flaw which allows arbitrary code execution on a system with UMCI enabled, such as Device Guard which is enabled by default on Windows 10 S.
The highly technical but concise description of the flaw is detailed below:
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.
It is important to note that the vulnerability only affects systems with Device Guard enabled - which is primarily Windows 10 S - and that it cannot be exploited remotely. An attacker would already need to have the code running on the system in order to modify registry entries, which considerably lowers the severity of the issue. Google notes that the issue itself isn't quite as serious if other possible methods of bypass were fixed such as Remote Code Execution (RCE) in Edge, which still means that it is classified as a "medium" severity issue.
The timeline of the vulnerability disclosure is quite interesting. Google reported the flaw to Microsoft on January 19 but the Redmond giant was unable to fix it before April's Patch Tuesday. As a result, Microsoft requested a 14-day extension but informed Google that a fix will be rolled out in the May Patch Tuesday. Since this timeframe exceeded the grace deadline as well, Google refused Microsoft's request and didn't award it the extra 14 days.
Google then told Microsoft that the issue isn't quite serious and that there are still other bypass methods that the company has not fixed yet. Last week, Microsoft once again requested an extension in the deadline claiming that it would be resolved in the Redstone 4 (RS4) update, but Google rejected it saying that there's no firm date for the update, and "RS4 wouldn't be considered a broadly available patch" anyways.
With the standard 90-day deadline exceeding today, Google has publicly disclosed this flaw, which mainly affects Windows 10 S. It will be interesting to see if Microsoft is forced to release a hotfix or if it still plans to roll out the fix with the Patch Tuesday on May 8.
