Windows: XmlDocument Insecure Sharing Elevation of Privilege
When an AppContainer sandboxed application creates a partial trust class it’s instantiated inside a Runtime Broker running at the normal user privilege. While Windows.Data.Xml.Dom.XmlDocument is marked as Base Trust so would be instantiated inside the same process as the creator, there’s a number of partial trust classes which expose a XmlDocument object. An example of this is the ToastNotificationManager class which expose a XmlDocument through the GetTemplateContent static method. This is exposed to all normal AC and also has explicit permissions to allow lpacAppExperience capability to access it which all Edge Content LPAC processes have. The problem with XmlDocument is it doesn’t custom marshal the object over process boundaries, this means that the XmlDocument which is created by ToastNotificationManager stays in the Runtime Broker. If there’s any security issues with the use of XmlDocument interface then that’s a problem. Looking at the class it’s implemented inside msxml6.dll and is basically a MSXML.DOMDocument.6.0 class in all but name. Checking what interfaces the class supports you find the following (partial list): IPersistMoniker, IPersistStream, IPersistStreamInit, IServiceProvider, IStream, IXMLDOMDocument, IXMLDOMDocument2, IXMLDOMDocument3, IXMLDOMNode, Windows::Xml::Dom::IXmlDocument, Windows::Xml::Dom::IXmlDocumentIO, Windows::Xml::Dom::IXmlDocumentIO2, Windows::Xml::Dom::IXmlNode, Windows::Xml::Dom::IXmlNodeSelector, Windows::Xml::Dom::IXmlNodeSerializer. What stinks here is that the IXMLDOMDocument interface is implemented by the same class which implements the IPersistMoniker interface. This means that the XmlDocument can be used to load a file from a remote location using the IPersistMoniker::Load method.
