New issue
Advanced search Search tips

Issue 1328 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2017
Cc:



Sign in to add a comment

Windows: WLDP/MSHTML CLSID UMCI Bypass

Project Member Reported by forshaw@google.com, Jul 19 2017

Issue description

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.

 
poc.zip
665 bytes Download
Project Member

Comment 1 by forshaw@google.com, Jul 20 2017

Labels: MSRC-39754
Project Member

Comment 2 by forshaw@google.com, 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.
Project Member

Comment 3 by forshaw@google.com, Oct 10 2017

Project Member

Comment 4 by forshaw@google.com, Oct 10 2017

Status: Fixed (was: New)
Project Member

Comment 5 by forshaw@google.com, Oct 13 2017

Labels: -Restrict-View-Commit
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