Google’s Project Zero exposes unpatched Windows 10 lockdown bypass

Google's Project Zero researchers have published details and a proof-of-concept code for a method to bypass a Windows 10 security feature.
 
Once again, Project Zero has knocked back Microsoft's request for an extension to the 90-day deadline it gives vendors to either disclose or release a fix for bugs it finds.
 
The newly disclosed bypass is a medium-severity issue that affects Windows 10 S or any Windows 10 machine with user mode code integrity (UMCI) enabled, such as enterprise Windows 10 PCs configured with Microsoft's virtual container known as Device Guard.
 
Project Zero researcher James Forshaw released a detailed description and proof-of-concept code for the bypass that allows an attacker to gain persistent code execution on a machine.
 
The bug itself resides in .NET and how it behaves within the Windows Lockdown Policy (WLDP). The researcher downplayed the seriousness of disclosing the bug in the absence of a patch due to the existence of two other known and unfixed Device Guard bypasses in the .NET framework.
 
"So this issue isn't as serious as it might have been if all known avenues for bypass were fixed," he wrote.
 
The bug also can't be remotely exploited and would require an attacker to have already infected a machine with malware. However, Forshaw notes that an attacker could get around this obstacle by exploiting another remote code execution bug in, say, Edge.
 
Google reported the issue to Microsoft on January 19. Microsoft confirmed the issue about three weeks later and said it could not be fixed by April's Patch Tuesday deadline due to an "unforeseen code relationship".
 
The two tech giants re-engaged in the beginning of April to haggle over disclosure dates. Microsoft asked for two weeks' grace on the 90-day deadline, which Google denied, and then asked Google to hold off disclosing the bug until May's Patch Tuesday, which Google also knocked back.
 
Microsoft last week pitched the idea of an extension until its upcoming Redstone 4 Windows 10 release, which will have a fix. However, Google denied this request too because Microsoft hasn't set a firm date for its Spring Windows 10 release.
 
Here's Forshaw's technical explanation of the bypass:
 
"The WLDP COM Class lockdown policy contains a hard-coded list of eight 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," he wrote.
 
"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."
 
However, Forshaw said it turns out that .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," he said.
 
"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."

---