Windows: COM Desktop Broker Elevation of Privilege
The COM Desktop Broker doesn’t correctly check permissions resulting in elevation of privilege and sandbox escape. Windows 10 introduced “Brokered Windows Runtime Components for side-loaded applications” which allows a UWP application to interact with privileged components by allowing developers to write a custom broker in .NET. Rather than handling this with the existing Runtime Broker a new “Desktop Broker” was created and plumbed into the COM infrastructure. This required changes in COMBASE to instantiate the broker class and RPCSS to control access to the broker. The stated purpose is only for use by sideloaded enterprise applications, specifically .NET based ones. Looking at the checks in RPCSS for the activation of the broker we can see the check as follows: HRESULT IsSideLoadedPackage(LPCWSTR *package_name, bool *is_sideloaded) { PackageOrigin origin; *is_sideloaded = false; HRESULT hr = GetStagedPackageOrigin(package_name, &origin); if (FAILED(hr)) return hr; *is_sideloaded = origin != PackageOrigin_Store; return S_OK; } This check is interesting because it considered anything to be sideloaded that hasn’t come from the Store. Looking at the PackageOrigin enumeration this includes Inbox applications such as Cortana and Edge both of which process potentially untrusted content from the network. Of course this isn’t an issue if the broker is secure, but… For a start, as long as RPCSS thinks the current package is side-loaded this feature doesn’t require any further capability to use, or at least nothing checks for one during the process. Even in the side loading case this isn’t ideal, it means that even though a side loaded application is in the sandbox this would allow the application to
