A technical exploration by Google Project Zero has spotlighted a significant bug class in Windows technologies related to Object-Oriented Remoting frameworks such as DCOM and .NET Remoting.
These frameworks enable developers to create object-oriented interfaces bridging process and security boundaries.
However, their flexibility introduces vulnerabilities, as evidenced by the “trapped object” bug class.
The flexibility of remoting technologies allows for cross-boundary object exposure, but when certain unsafe objects such as COM or .NET libraries are inadvertently shared, they can be leveraged for privilege escalation or arbitrary code execution.
A particularly common scenario involves XML document objects. If improperly secured, these objects can allow an attacker to execute code in the server’s process.
For example, Microsoft encountered CVE-2019-0555 when exposing an object assumed safe for remote access, which attackers exploited to bypass privilege boundaries using legacy XML scripting features.
IDispatch: A Vector for Exploitation
The IDispatch interface, a cornerstone of OLE Automation in COM, was central to this study.
Designed for dynamic late-bound communication with scripting languages, IDispatch supports methods like GetTypeInfo
, which can unintentionally make objects vulnerable to exploitation.
Google’s researchers demonstrated how malicious actors could leverage IDispatch to query and instantiate specific COM objects in privileged server contexts.
One highlighted exploitation chain involves enumerating type libraries from the COM interface, identifying unsafe classes, and invoking methods or creating objects within the server’s privilege level.
Through PowerShell scripts, researchers analyzed type libraries, inspected dispatched interfaces, and identified trapped objects that could execute high-privilege actions remotely.
By exploiting IDispatch’s CreateInstance
method, attackers could instantiate objects in the server environment, opening doors to potential privilege escalations.
Injection into Protected Processes
Further expanding on their findings, Project Zero unveiled insights into leveraging these vulnerabilities for injecting code into Windows Protected Processes.
Using techniques like COM class registration hijacking and .NET remoting misuse, they demonstrated how trapped COM objects could facilitate arbitrary code execution even in highly secure contexts, such as accessing LSASS (Local Security Authority Subsystem Service).
However, this exploration revealed countermeasures in newer Windows versions like 11 24H2.
Protected process mitigations block certain object types from loading due to signing-level enforcement.
Researchers worked around this by redirecting type library registrations to compatible objects.
This allowed them to execute their Proof of Concept on older Windows and partially on Windows 11, exposing gaps in current mitigations.
While outright privilege escalation was not achieved, Project Zero highlighted the broader implications of trapped COM objects via IDispatch interfaces.
They illustrated how improper COM object remoting can lead to injection attacks, particularly on critical Windows components.
Microsoft’s mitigations, including signing-level enforcement, were noted as an essential step forward, though gaps persist.
The researchers concluded with recommendations for further securing remoting frameworks and combatting the exploitation of trapped objects in sensitive processes.