Windows: Runtime Broker ClipboardBroker EoP
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 traditonal IStorage sandbox escape by writing a dll to the IStorage object and then calling LoadLibrary on it.
