EDB-ID: 41902 | Author: Google Security Research | Published: 2017-04-20 | CVE: CVE-2017-0211 | Type: Local | Platform: Windows | Aliases: N/A | Advisory/Source: Link | Tags: Local | Vulnerable App: N/A |
Windows: Runtime Broker ClipboardBroker EoP
Platform: Windows 10 10586/14393 not tested 8.1 Update 2
Class: Elevation of Privilege
Summary:
The Runtime Broker’s Clipboard Broker allows any low IL/AppContainer (such as Edge or IE EPM) to get access to an OOP IStorage object through the ClipboardBroker leading to a sandbox escape.
Description:
Windows 8 and above have a COM service running as the normal user called the Runtime Broker which performs a few services for AppContainer and low IL processes. One of these services is brokering access to the Clipboard which would normally be restricted. I know at minimum this is used in Edge content processes.
The broker does prevent things like setting data to the current IDataObject but allows AC applications to set their own IDataObject. To do things like blocking SetData the application provided IDataObject object is wrapped by an OLE32 implementation. We can abuse this functionality by first setting our own IDataObject using SetClipboard then calling GetClipboard to get back the OOP IDataObject wrapper. As this is a wrapper it will never marshal the original IDataObject back to the caller so calling methods on the wrapper will execute code inside the Runtime Broker process running outside the sandbox.
If we call something GetData on the OOP wrapper requesting an IStorage object the wrapper will attempt to callback to the IDataObject from the the application to see if that data exists. It does this initially using the GetDataHere method. As this method takes an IN/OUT STGMEDIUM structure it needs to be initialized, it so happens that in this case it will initialize it with an empty READ/WRITE IStorage object. This is passed back to the calling application, however because the default implementation of IStorage does not use custom marshaling (at least for OOP) the IStorage object also never leaves the runtime broker process.
We can now do the traditional dance of querying for IPropertyBag, settings a serializable object (such as MSXML DOMDocument) then reading it back out again. Again this XML DOMDocument object is trapped in the Runtime Broker process, so by running some JScript in an XSLT transform we can get arbitrary code executing outside of the sandbox.
Presumably you wouldn’t even need to do this loopback trick if some other application has pasted an IStorage object to the clipboard, however by doing this we can exploit at any time. I’m sure there’s plenty of edge cases where access to an IStorage object is possible.
The security on Runtime broker allows any AppContainer and low IL application to Launch/Activate and Access, so this would be a general sandbox escape from a number of sandbox types.
Proof of Concept:
I’ve provided a PoC as a C# source code file. You need to compile it first. Note that depending on the version of Windows the IIDs for the various interfaces might change, the PoC is only setup for 10.14393 updated to January 2017. Also the PoC must be considered a foreground window otherwise getting/setting the clipboard will fail. In a real scenario this isn’t an issue, I’ve verified that Edge content processes do use the broker if you copy and paste.
1) Compile the C# source code file.
2) Execute the PoC executable as a low privileged user such as AppContainer or low IL.
3) Notepad should appear running at medium as a child of RuntimeBroker.exe.
Expected Result:
Access blocked to storage objects in the clipboard.
Observed Result:
The storage object is accessed and abused to escape the sandbox.
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/41902.zip
