DLL/COM handling vulnerabilties in CIS 6.0 - info and discussion of exploits

[Updated 21/11/2012 updates are in blue]

What CIS means by COM and COM handling
It appears that CIS regards COM handling as embracing all facilities provided for handling DLLs and other objects that communicate using COM including DCOM.

So it includes security measures aimed at preventing exploitation basic dynamic linking in Windows as well as those aimed at components that make full use of Microsofts Component Object model run-times.

Why COM is a challenge.
Window’s basic dynamic linking facilities are a problem because:

[ol]- It’s a protocol that allows one executable object to ask for services from another dependent object. Either (or both) of this pair could be malware. It’s no different from other simpler comms protocols in this respect of course, but in other ways there’s considerable complexity to exploit…

  • The number of dependent objects on any machine can be very very large and many (even from OS vendors) are unsigned. It’s not easy to create a comprehensive whitelist such a large number of objects, sandboxing a large number of unrecognised objects would cause performance and reliability problems, and alternative backlisting approaches make the computer vulnerable to zero-day attacks
  • The dependent objects can request services from each other. [/ol]

Components that make fuller use of COM are a problem because:

[ol]- The client object need not specify exactly what server object shall provide the requested service. Any object that can fulfill the request may do so.

  • The client object does not need to specify the location of the server object [edit: though priority is given to one in the local directory].
  • COM is used as part of the OS to provide basic, commonly used, services to executables.
  • Dependent objects can register to intercept calls to provide services to all executables on a machine. (Global hooking)
  • COM involves several different invocation and communication mechanisms, all of which potentially need monitoring. Specifically it supports:
    [li]in process comms in which the dependent objects, DLL files, are loaded ‘injected’ into the client executables, EXE files’, memory space every time the executable runs.
  • Out of process comms in which the dependent objects, EXE files, may already be running separately or may be invoked
  • Distributed out-of process comms (similar to out-of process comms, but between machines)

I’ll deal mainly with the threat from in-process COM here. I have no specific information about how the out-of-process types are handled. Possibly via CIS’s standard BB facilities? Worth investigating if anyone has the time. Some resources here and here.

Rules for in-process COM

Previously the CIS 5.0 autosandbox passed COM-related actions to D+ for handling, leading to COM alerts.

The CIS 6.0 replacement, the behavior blocker (BB) deals with COM-related activity itself. It silently allows or blocks actions. Given that wholesale whitelisting is not possible, CIS must control COM objects by controlling the actions required to set up and run them. I know of 4 possibilities:

  • Controlling the dropping of DLLs. I guess the damage that DLLs can do is no more location dependent than it is for client EXE files. So AFAIK the standard ‘protected folder file’ list is used for this.
  • Controlling the registering of DLLs to provide services. For example registering a global hook to intercept requests for a common OS service. The damage that .DLLs can do is very much dependent on what services they register to provide, and how global those services are. So my understanding is the BB does provides special controls for this.
  • Controlling the in injection of .dlls into processes at run time. The damage that .dll’s can do is very much dependent on what executables they are injected into, and probably the privs with which the executables are running. So the BB does provide special controls for this.
  • An obvious possibility is controlling individual communication instances. But I think this would not be easy for in-process comms?

The rules the BB actually uses control the above actions depending on the trusted/untrusted status of the client (.EXE) and server (.DLLs). The rules as I understand them are supposed to be:

  • DLLs can get trusted just like EXE files by being dropped by a trusted .exe (eg an installer), being on the whitelist etc. Such DLLs can also be registered to provide any service, anywhere in the registry, including the global hook location.
  • DLLs dropped by an untrusted EXE (eg installer) will be regarded as untrusted. They cannot be registered as global hooks, but can be registered to provide other services. However only BB’d EXE’s can use (ie be injected with) them, non-BB’d EXEs cannot.
  • Possibly implied but not stated is that the injection process means that the injected DLL automatically (or by default) inherits the security restrictions (ie the BB’ing) of the host (injected) EXE because it runs in-process. Egemen did not actually say this during mods Beta, but if you assume it the rules make more sense. Maybe you guys can confirm this if you are programmers. Note that there seems to be info on the internet to suggest that the DLL can run with different permissions if requested. Any one know about this?
  • There is an experimental setting is probably not in the Beta release, and would probably only be invoked occasionally. I’ll post it maybe next version if I think it has been implemented and/or if I think reasonable.
  • BB’ing and auto-virtualisation have pretty much the same effect as I understand it. So you can substitute one for the other in the above discussion. Not sure what happens if something is trusted and virtualised, but I guess it’s treated as if BB’d as well.

CLT could be used for investigating some aspects of CIS’s control of COM. But you have to be v careful how you use it. I will post on this soon now I have done the COM analysis. Otherwise you can look for programs which eg install global hooks like OpenWide

Please note all this is only my understanding. I may have something wrong, if so Egemen or another dev may post accordingly!

Best wishes


Acknowledgements: many thanks to Kail another mod for pointing out that CIS’s facilities were as much aimed at dynamic linking as at components that make fuller use of the Component Object Model

Please feel free to post results of any COM investigations, possible COM-related vulnerabilities below.

The topic is NOT locked.

Best wishes


It was supposed to be fixed in version 6 as promised by egemen but nothing so far. I wonder why Comodo HIPS can,t give a simple alert just like OnlineArmor.

Online Armor simply beats Comodo in dll malware interception, file infectors, ransomware etc.

Can developers work on this. Thanks

I will try to post more screenshots of OA later.

[attachment deleted by admin]

but OA is not compatible with many antivirus :cry:

Which ones for example? I am using OAP and tried it with Avast, Nod32, webroot, Norton, etc… never had any issues.

Question here is, why do legitim signed apps even parse some random DLL’s that are located inside the same folder? Makes no sense, why would an EXE parse some random DLL if it’s not coded to specifically cal its functions!?

It’s not about a random dll. It’s about how a windows application determines which dll to load if a function is called. Dlls placed in the program’s directory and (probably more problematic) in the working directory supersede dlls in the windows folders.

I know that but that doesn’t change the fact that such behavior is stupid by design on the OS level.

Please watch the NAME of the .dll file in the picture!
(OA block the .dll file whose name is the same as that of the system dll file.)

OA can not block this malware.

So far, only defensewall hips can REALLY block this kind of malwares.
(DW will automatically sandbox the .exe file even if it is in the trusted list.)

[attachment deleted by admin]

The topic is, that it would be a valuable addition to CIS, to help preventing attacks of that kind. It’s not about the sense of the underlying Windows behavior.

We can easily intercept loaded DLLs and ask users what to do. However this, although will make some people happy, will not make 99% of users happy. Also there are similar methods that doesn’t use DLLs but power point files, DOCx files as well.

We have a silent proactive solution for this. However due to certain legal and technical problems, it is just not in CIS 6 as expected. You will be the first ones to test it soon and give feedback.

In the mean time there are tons of mitigating factors in CIS 6 for this, kiosk, AV, virtual browsing etc. These reduce the attack surface significantly for now.

I’m very happy to hear this.

Please let us know when you can provide more details, but until then, I’ve just got to say that :rocks:.

Sounds really interesting egemen, thanks for letting us know. I really look forward to testing the new technology

Great News!

I remember that issue of interception of dlls in comodo has already been a problem in previous versions by its thousands of warning about what to do with the dll.
for me has always been excellent, but about 90% of people complained.

Because I think OA people are just using a hack to intercept such malware, may be they have coded dll names in OA data base. Their interception is also not real indeed.

Wish comodo HIPS can come with some real genuine interception for such attacks.

Good to know. Sure we don,t want thousands of all legit dll loading alerts.

Will it address these issues too.

1- File infectors
2- Ransomware


[attachment deleted by admin]

Two methods:

BB is enabled.
The sandbox level is “limited”.

HIPS is enabled.
The item for the "direct disk access " is ticked.

Yep. Let me sandbox level"Fully Virtualized" as well.

I noted that there may be compromise between security and usability. As CIS default setting is inclined to usability for general users.

I think it will be useful if you would write up a post for hardening of CIS 6 when it launch. :wink: