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 jasoncat_private
This archive was generated by hypermail 2b30 : Mon Jul 29 2002 - 20:42:01 PDT