Windows COM Object Vulnerability Enables Remote Code Execution for System Takeover

A critical bug class termed “trapped object” has been identified by Google’s Project Zero team.

This vulnerability primarily arises from improper use of object-oriented remoting technologies like DCOM and .NET Remoting, which facilitate cross-process and cross-security boundary services.

These systems, though designed for flexibility, inadvertently expose certain unsafe objects, leading to potential remote code execution (RCE) or privilege escalation.

Unsafe Object Remoting

The vulnerability lies in remoting unsafe objects across boundaries.

For example, developers might marshal XML Document objects by reference during runtime, unaware that this exposes scripting capabilities like XSLT execution in the server’s context.

A historical instance of this issue was CVE-2019-0555, where developers unintentionally shared an XML DOM object with outdated interfaces, allowing attackers to breach sandboxes.

Another scenario involves asynchronous marshaling, where objects like .NET’s FileInfo can be marshaled both by value and reference.

Attackers exploit this duality to trap objects in server processes, gain elevated access, and invoke privileged methods such as file creation on servers.

Furthermore, attackers can abuse APIs, like CoCreateInstance to instantiate arbitrary classes and execute malicious code.

A notable example was CVE-2017-0211, which exploited COM Structured Storage objects to gain elevated privileges.

Role of IDispatch Interface in Escalating the Threat

The IDispatch interface, a key feature of OLE Automation designed for late binding in COM, facilitates this vulnerability.

Exploits occur when objects like ITypeInfo are remoted.

Despite type libraries being designed for remote invocation, certain methods such as CreateInstance inadvertently instantiate COM objects in the server’s process context.

Attackers can enumerate unsafe classes within type libraries to target objects that are otherwise intended for local access.

For example, a type library for the WaaSRemediationAgent class was identified as exposing out-of-process objects like WaaSRemediationLib, which attackers could potentially exploit to craft escalated permissions.

According to Google, this issue also extends to injection into Windows Protected Processes (PPL).

The Project Zero researcher demonstrated exploiting remoted type libraries to inject malicious code into processes like LSASS under PPL-Windows protection levels.

By redirecting registrations of safe classes (e.g., StdFont) to vulnerable classes and using .NET-based reflection, attackers could bypass process protections to execute arbitrary code.

However, newer Windows 11 protections, such as enhanced signing checks via cached signatures (NtSetCachedSigningLevel), mitigate these attacks by blocking type libraries lacking proper signing levels.

While Microsoft has introduced some mitigations, such as stricter validation of type libraries in protected processes, this bug class remains a systemic issue in remoting technologies.

Developers must ensure that:

1. Only safe objects are remoted across boundaries.
2. Proper validation mechanisms are in place to block unsafe object marshaling.
3. Unnecessary APIs like CoCreateInstance are restricted in high-privilege environments.

Although this research didn’t directly escalate privileges in its demonstration, Project Zero emphasizes the importance of these findings in preemptively mitigating potential exploitation vectors.

Are you from SOC/DFIR Teams? – Analyse Malware Files & Links with ANY.RUN Sandox -> Try for Free