Jon Larimer IBM
download slides (PDF)
Microsoft Windows allows for the registration of COM objects in the user hive of the system registry, and these per-user COM objects generally take precedence over COM objects registered computer-wide. While this offers a lot of flexibility in the way COM objects are installed and allows unprivileged users to install COM components that won't affect other users, there are a few security issues that can be taken advantage of by malicious software.
Because the COM subsystem will load per-user COM objects before the machine-wide objects, malware can register malicious objects in a way that allows for a type of process injection to load malicious code into a target process. In some cases, this is possible even when the process is already running.
This technique can also be used by malware for persistence, without relying on the traditional method of using the 'Run' keys and without requiring administrator privileges. It is also possible to use this technique to create a user-mode rootkit that can hide files and registry keys from other user-mode processes.
And finally, while Microsoft's documentation states that the COM subsystem in Windows Vista and later versions will not load per-user COM components for elevated processes, it's possible to bypass this restriction in some cases to execute an elevation of privilege attack.
Luckily, these attacks can easily be detected and there are a variety of ways to mitigate the dangers of per-user COM objects.
