James Forshaw of Google Project Zero has shed light on a significant security vulnerability in Windows related to accessing trapped COM objects through the IDispatch interface.

This research highlights an intriguing bug class that exploits cross-process communication features in object-oriented remoting technologies like COM objects and .NET Remoting, potentially allowing attackers to execute code in higher-privileged server processes.

Understanding the Trapped Object Bug Class

The vulnerability stems from the flexibility of remoting technologies that allow objects to be shared between client and server processes.

While designed to simplify the development of cross-boundary services, these features can inadvertently expose unsafe objects.

Forshaw notes that if an object is returned and marshaled “by reference,” it remains in the server process, making it vulnerable to exploitation. One such example is XML libraries, which could allow remote code execution by leveraging scripting features.

Specific cases, such as CVE-2019-0555, illustrate how developers assumed safety in certain object implementations, only to inadvertently expose dangerous interfaces.

Another example, CVE-2017-0211, demonstrated how attackers could use the IPropertyBag interface to create arbitrary COM objects in a server’s context, potentially elevating their privileges.

The Role of IDispatch and Type Libraries

The IDispatch interface—a key part of OLE Automation—enables late binding of COM objects for scripting languages like VBA and JScript.

By leveraging the type library mechanism, attackers can exploit the CreateInstance method in remoted objects to instantiate COM objects within a server’s process. This can be used to gain control over the server, bypassing security boundaries.

Forshaw demonstrated this issue using tools like his OleView.NET PowerShell module, identifying several COM classes exposed through local services.

While investigating specific service classes, such as WaaSRemediation, Forshaw explored how these hidden vulnerabilities could be exploited for privilege escalation or injection attacks.

PS> $cls = Get-ComClass -Service

PS> $cls | % { Get-ComInterface -Class $_ | Out-Null }

PS> $cls | ? { $true -in $_.Interfaces.InterfaceEntry.IsDispatch } | 

        Select Name, Clsid

Name                                       Clsid

----                                       -----

WaaSRemediation                            72566e27-1abb-4eb3-b4f0-eb431cb1cb32

Search Gathering Manager                   9e175b68-f52a-11d8-b9a5-505054503030

Search Gatherer Notification               9e175b6d-f52a-11d8-b9a5-505054503030

AutomaticUpdates                           bfe18e9c-6d87-4450-b37c-e02f0b373803

Microsoft.SyncShare.SyncShareFactory Class da1c0281-456b-4f14-a46d-8ed2e21a866f

Injection into Protected Processes

The research took an interesting turn when Forshaw analyzed the WaaSRemediationAgent class, a Windows service running as a Protected Process (PPL-Windows).

PS> $obj = New-ComObject -Clsid 72566e27-1abb-4eb3-b4f0-eb431cb1cb32

PS> $lib = Import-ComTypeLib -Object $obj

PS> Get-ComObjRef $lib.Instance | Select ProcessId, ProcessName

ProcessId ProcessName

--------- -----------

    27020 svchost.exe


PS> $parsed = $lib.Parse()

PS> $parsed

Name               Version TypeLibId

----               -------- ---------

WaaSRemediationLib 1.0      3ff1aab8-f3d8-11d4-825d-00104b3646c0


PS> $parsed.Classes | Select Name, Uuid

Name                          Uuid

----                          ----

WaaSRemediationAgent          72566e27-1abb-4eb3-b4f0-eb431cb1cb32

WaaSProtectedSettingsProvider 9ea82395-e31b-41ca-8df7-ec1cee7194df

While Microsoft considers PPL not to be a strict security boundary, it restricts certain tools, like script engines, from being loaded into protected processes. Forshaw proposed and tested a novel injection method targeting the IDispatch-based interface.

By redirecting the COM registration of a vulnerable object (e.g., StdFont) to a malicious class, attackers could potentially inject .NET-based payloads or other harmful code into the protected process.

Forshaw showed how exploiting registry keys and .NET COM reflection could load arbitrary assemblies, enabling code execution.

While the proof-of-concept worked on Windows 10, Forshaw encountered challenges on Windows 11 (24H2).

Microsoft had introduced mitigations, such as cached signing level validations, which blocked libraries that lacked Windows-level signing.

However, Forshaw found a workaround by using a 32-bit version of the type library, proving that the exploit remains viable with enough effort.

Mitigations and Implications

Although Forshaw’s research did not directly demonstrate privilege escalation, it highlighted IDispatch interfaces’ risks in remoting technologies.

Attackers with administrative privileges could use the attack method to inject code into a protected process, such as LSASS, or even by standard users if suitable COM servers are exposed.

Forshaw noted that Microsoft has addressed some attack vectors by improving type library validation, but certain areas remain vulnerable.

Notably, while this vulnerability requires significant expertise to exploit, it reinforces the need for secure object handling across process boundaries

Forshaw’s blog underscores how subtle design decisions in remoting technologies can lead to significant security risks.

The ability to trap and manipulate COM objects across privilege boundaries serves as a reminder of how complex systems can be exploited in unintended ways.

While the demonstrated attacks require administrative privileges or careful setup, they highlight an ongoing problem with how object-oriented remoting technologies handle cross-boundary interactions.

As always, users and organizations are encouraged to keep their systems updated and audit services for exposed interfaces to mitigate potential risks. Meanwhile, Microsoft may need to continue refining its mitigations to address these advanced attack vectors.

This research serves as a reminder of the complexities and challenges in securing modern operating systems, particularly when dealing with legacy technologies like COM.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates