Despite Microsoft's objections, Google release a jailbreak for Windows 10 S

Reading time icon 3 min. read


Readers help support MSPoweruser. When you make a purchase using links on our site, we may earn an affiliate commission. Tooltip Icon

Read the affiliate disclosure page to find out how can you help MSPoweruser effortlessly and without spending any money. Read more

Google’s Project Zero team has done it again, releasing a “Medium Severity” exploit for Windows 10 S which means users will be able to run arbitrary code on Microsoft’s locked down operating system, Windows 10 S.

The flaw is due to how Windows 10 S verifies the identity of a list of high privilege components, which is to say very poorly.

In detail Google describes it as such:

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.

Windows 10 S is the main OS affected, and in the absence of a remote code, the exploit would mean hackers would need physical access to the PC  to run the initial code.  Given that Windows 10 S is often used in situations where the user is not trusted (such as schools) however this could mean that smart users will be able to hack the operating system and run arbitrary code, which could be a step to fully unlocking the operating system.

Microsoft was notified of the flaw on January 19th but planned to release the fix as part of Redstone 4.  This was however well beyond Google’s 90-day disclosure window, and despite Microsoft’s repeated request for an extension Google has now released detailed information on the exploit.

Given that Windows 10 S is not currently widely deployed I suspect not much will come from this small spat, but it is interesting that Microsoft failed to anticipate this issue, which suggests Microsoft needs to work harder on auditing their software and methods for security implementation issues.

Via Neowin

More about the topics: google, google project zero, microsoft, security, Windows 10 S