Malicious COM Surrogates

["Jason Coombs" <jasonc () science org>]

Aloha,

I've been considering the risk of a malicious COM surrogate and wondering if
others have looked into this in the past.

Every in-process COM component can be configured via Registry/Active
Directory settings to launch in a COM surrogate through DllSurrogate - each
can also be forced out-of-process through LocalService, in which case COM
automatically handles marshaling and the client code gets a proxy and a stub
instead of the in-process DLL it may assume it got by activating the
component.

Why couldn't a malicious custom COM surrogate be written to host in-process
COM components configured to launch within the custom surrogate through
DllSurrogate setting? Similarly, why couldn't a malicious custom service
effectively suck all COM components into its process space simply by setting
LocalService for every registered COM class?

The apps that depend on the COM components referenced by particular CLSID's
would still function, but the malicious DllSurrogate or LocalService process
would have complete control over them.

Thoughts? References to examples where this has already been done and the
vulnerability patched?

Securing Active Directory and the Registry from unauthorized tampering would
prevent such attacks, but the prospect of wrapping such a surrogate around
COM compliant code that carries out encryption and decryption using
symmetric key algorithms or that loads and uses asymmetric private keys for
digital signatures and other operations makes the potential for harm from
this type of attack more significant.

It's similar to an arbitrary code-injection attack except that the code
isn't injected within the security context of a host process, since the
malicious code is itself a host process... Any registered COM component that
a process activates and gives sensitive data to may be activating inside a
malicious surrogate process.

How would one defend against this threat?

Jason Coombs
jasonc () science org