Windows: WLDP/MSHTML CLSID UMCI Bypass
Project Member Reported by email@example.com, Jul 19 2017
Windows: WLDP/MSHTML CLSID UMCI Bypass Platform: Windows 10 S (thought should be anything with UMCI) Class: Security Feature Bypass Summary: The enlightened lockdown policy check for COM Class instantiation can be bypassed in MSHTML hosts leading to arbitrary code execution on a system with UMCI enabled (e.g. Device Guard) Description: Scripting hosts are supposed to check against the Windows Lockdown Policy (WLDP) before instantiating arbitrary COM classes. This is typically done by calling WldpIsClassInApprovedList from WLDP.DLL before instantiating any COM class. For example in the case of JScript’s ActiveXObject the ProgID is passed to CLSIDFromProgID by the script host and the resulting CLSID is passed to WLDP to determine what’s allowed. It’s possible to circumvent this check by using the COM TreatAs key to redirect one of the limited (8) allowed CLSIDs to an arbitrary class and get it instantiated. However you can’t do this using ActiveXObject as CLSIDFromProgID will return the resulting CLSID from looking up TreatAs. That said there is a race condition here. However in an MSHTML Local Machine Zone scenario you can bypass it by using an OBJECT tag. In this case MSHTML parses the classid attribute and checks that CLSID against WLDP. It then proceeds to create it using CoCreateInstance which follows TreatAs and creates a different object. This does require modification of the registry to work, but I think that’s in scope. The reason I’m reporting this one is I think it’s a bug in MSHTML, rather than in an application you can easily block (at least if you want to disable Proof of Concept: I’ve provided a PoC is two files, a text file to set-up the registry and a HTML file. The registry file is in the REGINI format which allows it to work on Win10S as while reg.exe and regedit.exe are blocked regini.exe isn’t. The HTML file can be run inside IE or my prefered option HTML Help. You could even make the PoC file a CHM but I didn’t. The PoC can bootstrap things like untrusted .NET but for simplicity it doesn’t. 1) Unpack the PoC and ensure the HTML file does NOT have MOTW. 2) From the explorer Run dialog execute “regini path\to\keys.txt” 3) Execute the HTML file from the Run dialog using “hh path\to\shell.html” Expected Result: The class creation should fail. Observed Result: The class creation succeeded and the HTML file executed notepad. This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.
Jul 20 2017,
Aug 15 2017,
MSRC sent an assessment on the issue and decided it's by design. However the assessment said it's by design that HTML Help does not enable Local Machine Zone Lockdown as per https://msdn.microsoft.com/en-us/library/ee330732(v=vs.85).aspx#local_mach_lock. While enabling LMZ Lockdown (sortof) fixes the issue reported it's completely unrelated to the issue at hand with the handling of COM classes under the Windows Lockdown Policy when running with UMCI. I informed MSRC about my concerns with their assessment and I am waiting for a response.
Oct 10 2017,
Oct 10 2017,
Oct 13 2017,
Nov 9 2017,
Nice finding, however the "issue" is well known (I guess) with regards to the 'TreatAs' Registry setting. On Windows 7 and above we have got a lot of this on many old OLE objects, so the application parsing content that has reference to a registered COM class which has the 'TreatAs' registry key will automatically use the class/object specified by its CLSID. For what I have read, this issue could happen in other security zones if the "Initialize and script ActiveX not marked safe for scripting" setting was set to "Prompt" instead of "Deny/Disallow", and if you change it to "Allow", then arbitrary ActiveX can be scripted. So, using eg. 'reg.exe' to change this setting for the Internet Zone, would have the same effect, since it can be done by any user (restricted or Admin). That said, I am quite surprised Microsoft patched this one. Cheers!
Sign in to add a comment