| Windows: WLDP/Scriptlet CLSID UMCI Bypass |
‹ Prev
3 of 3
|
|||
| Project Member Reported by forshaw@google.com, Aug 11 | Back to list | |||
Windows: WLDP/MSHTML CLSID UMCI Bypass Platform: Windows 10 with UMCI Class: Security Feature Bypass Summary: The enlightened lockdown policy check for COM Class instantiation can be bypassed in Scriptlet hosts leading to arbitrary code execution on a system with UMCI enabled (e.g. Device Guard) Description: This is effectively a variant on the bug reported as case 39754. In that case the issue was with MSHTML's handling of object elements in an HTML page. As the object was specified using a CLSID it the WLDP check was only for that top level class but it was possible to redirect it to an arbitrary COM class using a TreatAs key in the COM registration. This variant instead uses scriptlets, which can be executed on their own, or as WSF files inside WSH. These file formats also support an object element which has the same behavior. Proof of Concept: I’ve provided a PoC as two files, a text file to set-up the registry and a WSF file. The registry file is in the REGINI format. The WSF should be run in wscript/cscript which means you can't test this on Win10S by default. 1) Unpack the PoC and ensure the files do NOT have MOTW. 2) From the explorer Run dialog execute “regini path\to\keys.txt” 3) Rename the poc.txt file to poc.wsf. 3) Execute the WSF file from the Run dialog using “wscript path\to\poc.wsf” Expected Result: The class creation should fail. Observed Result: The class creation succeeded and the WSF 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.
Project Member
Comment 1
by
forshaw@google.com,
Aug 11
,
Nov 2
,
Nov 15
Deadline exceeded -- automatically derestricting. |
||||
| ► Sign in to add a comment | ||||