Google reveals a medium severity flaw in Windows 10 S

  1. Brink's Avatar
    Posts : 35,342
    64-bit Windows 10 Pro build 18317
       20 Apr 2018 #1

    Google reveals a medium severity flaw in Windows 10 S


    Google's Project Zero team is tasked with finding exploits in the company's own products as well as those developed by other firms. Members of the team discover flaws in software, privately report them to their respective developers, and give them 90 days to resolve the issue. If a fix is not broadly available before this deadline expires, the bug is revealed to the public. In special cases, a grace period is also awarded if the flaw is difficult to fix.

    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.

    Read more: Google reveals a severity flaw in Windows 10 S - Neowin
      My ComputersSystem Spec

  2.    20 Apr 2018 #1

    So... Win 10 S(ecure) isn't actually secure? Who'd a thunk it.
      My ComputerSystem Spec

  3.    21 Apr 2018 #2

    RickC said: View Post
    So... Win 10 S(ecure) isn't actually secure? Who'd a thunk it.

    Boy did I laugh with this comment.
      My ComputerSystem Spec


 

Related Threads
Read more: Google exposes security flaw in Microsoft Edge - Neowin
Source: Google won't fix login page flaw that can lead to malware download | ZDNet See also: Aidan Woods - Google's Faulty Login Pages
Read more fiction here
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 14:20.
Find Us