14 subjects in one article


I wrote an article about some problems in Comodo/Defense+, and my suggestions.

It’s too big to be split in 14 small items in the forum, so I deliver it here.

The source (well-formed) article is available here:

I paste a copy here, but as a raw text, as I did not find any way to convert OpenOffice text format to BB code, and it’s too big to be done by hand.

1 Abstract

Comodo Firewall offers good technical tools to secure processes activity under Windows.
They are grouped under the name “Defense+”.
While these tools are technically sufficient for controlling accurately the activity of processes and services, their poor graphical interface intelligence makes them often inefficient, and consequently sometimes dangerous.
In this article, I will describe some problems and how the interface should be improved, in Comodo and possibly in other security tools.
1.1 Leading concepts

When I read again this article, I see two leading concepts that I mention here to help your comprehension of the following chapters:


  Inheritance and application context.
  When a process calls another one, the child process should inherit the authorizations and restrictions of its parent process.

  A public security authorization requests list for each application.
  An application is a set of files and processes grouped in a directory, including its sub-directories.
  Each application should publish a text (XML) file describing all authorizations it requests for each of its processes (in fact, executable files).
  So security software and user can make security choices about the entire application at one time, all in a single page of selections.
  If this text does not exist, Comodo should create one automatically, reviewed by user.

2 For Comodo, and maybe other security software
2.1 The service hosting processes

Many processes are in fact hosts for “services”.
Services, as you may know, are programs that can be started, paused and stopped more easily than ordinary programs/processes, and are a the service of applications, including Windows. The operating system possesses many services, as well as anti-virus applications and many others.
The main host process is “svchost.exe”.

A big problem with Windows is: at Microsoft they had the very clever idea of grouping several services in one processes, mainly in the intend of reducing their resource consumption (notably memory).

This insecure concept has consequences:

* If one service hangs, it can make the operating system terminating the entire host process, and all its hosted services.
* There is a potential security breach, as the hosted services could access other services' information easier than if they were separated in different processes.

Under Windows Vista (and later O.S.), you can easily display the list of processes, by using the Task Manager, right-clicking on any “Svchost.exe”, selecting “Access to services”; that will show the different services hosted by this process host.
Unfortunately, Comodo is not that clever: when it displays a popup security warning, it does not tell us what service is originating the request, but only shows the host process.

My suggestion:

Comodo should always displays the service name in place of the host process name; using the short name and the description.
2.1.1 Process hosts

The same kind of problem occurs with some executable files only used as launchers.
Notably, “Rundll32.exe” is used to run many processes.

Open the Task Manager, and you will probably see a list of “Rundll32.exe” hosting many different things.
Par exemple: “rundll32.exe nvsvc.dll”, is a tool for Nvidia video chips.
By the way, you see that a DLL file can be launched, although DLLs are designed to be only tied to executables. In that example, Rundll32 is only a host, it does not do anything by itself.

My suggestion:

As for the service hosts, Comodo should display informations about the hosted executable file, not the host file.
2.2 Chaining process calls: inheritage

Another problem is when a process (a program) is internally calling another process, in order to accomplish a specialized task for example.
With Comodo, although we can attribute special authorizations for the main “parent” process, the chained “child” process does not inherit these authorizations.

The problem will be more clear with that example:

  1. We run an installation program called “Setup.exe”.
  2. This process run itself another program called “RegSvr32.exe”, which is used to add entries in the Registry.
  3. “Setup.exe” now runs another program called “wscript.exe”, which is a shell environment, just like the Command line environment.
  4. Wscript executes (runs) many commands, so many processes and actions in the O.S.
  5. Again, but for another reason, “Setup.exe” runs “wscript.exe”, which runs other processes.
  6. “wscript.exe” again. Etc…

At first step, Comodo asks us for authorizations for “Setup.exe”. Usually, we choose a predefined scenario: “Installer/Updater”, which gives it many authorizations.
At step 2, we agree, again, the quest, as it is necessary for the proper installation process.
At step 3-4, we agree again, although Wscript can do many things, including very insurethings.

From step 5 starts a series of requests for the same process Wscript. After a few calls, many users (as I) will be fed up of accepting requests and will check “Do not ask anymore” in the popup window, so that Wscript will obtain a definitiveright to do whatever it wants in the future.

We just created a security breach !

Because now, any process calling Wscript will obtain the right to do whatever it wants. Because Wscript can execute any process and do anything in the system. It is not as reduced as a specific tool. On the contrary, it is made to be able to do anything, just by launching other processes (programs).

My suggestion:

When we give an authorization to a process, its sub-processes (chained childs) inherit its rights and restrictions, but only it the (temporary) contextof the main process.
In our example, we give an “Installer/updater” temporary (or definitive) right to “Setup.exe”, and it transmits this right to its child processes, but only in its temporary context.

That means:


  We will see only one popup window questing rights, at the beginning of the installation.
* Wscript will not obtain definitive rights, so no security breach.


* Fewer requests from Comodo.
* Clarity of our security choice: a chain of processes is mainly depending on the parent process.
* No more security breaches generated due to our annoyance (no-one like clicking many times for apparently identical requests).


General launcheras the file Explorer (including the desktop) should not make inheriting its rights to the processes it runs: the two processes will be completely independent.

There are only a few couple of such programs, so it is not a problem to have a (partly predefined) list in Comodo’s configuration. No need to popup user for every process running another one.
2.2.1 More details for the command line environment

A batch file (a text file containing command calls, and called .BAT or .CMD), can be compared to a kind of application, as it does a particular job, in a particular context.
But it is executed (launched) by CMD.EXE, the command line environment of Windows.

But, contrary to ordinary executable files, CMD.EXE is a very particular program:

* It is mainly an host.
  CMD.EXE in itself is very generic.
* When executing a batch file, it interprets many commands, which lead to launch many programs/processes.

When you run a batch file, Cmd.exeis launched and start running commands and processes. If Comodo requests authorizations about that “application” (cmd.exe), you should not check “Do not ask anymore” because this rule will be applied to any other batch launched by Cmd.exe, which would be a security breach.

My suggestion:

Comodo should not consider Cmd.exe but its hosted “application”: the batch file.
Again, the important thing is the application’s context. All processes launched in this context should inherit from the batch file. And as all applications, the batch file should have a security requests file.

Comodo should have an option to declare any process as an host, and a method to determine the hosted file (the true application).
Usually, the hosted file is mentioned in the host command line. The method can be, for example “Cmd.exe %1”, with “%1” as the hosted “application” filename.
Another example: “rundll32.exe %1”.
2.3 Processes coming from nowhere

Sometimes, Comodo popup a request about an unknown process.
Who knows what is “ZupGlobPlop.exe” ???

Personally, in that case, each time I have to click on the process name, which fortunately displays an explorer properties window about the process. That is not very practical, and a bit slow, especially when I only needs to know the full path name of the process.

My suggestions:

* Always display the full path name of the process, accessible as a Hint.
* Always display the chain of parents of the process, accessible through a combo list.

2.4 These …@!?#… annoying DirectX disappearing popup windows

Games or other multimedia applications uses DirectX and 2 or 3 screens flipping. For that reason (and others), when Comodo displays a popup window in those applications, it often disappears very quickly.

In some circumstances, it already hanged my computer, as Comodo was pausing the application while another part (or thread) of the application was covering continuously the popup requests of Comodo. For unknown reason, I was not even able to recover the system control through the task manager. I had to reset the computer. That is why I always create a “Games” rule and apply it to any game’s executable file before running the game.

My suggestion:

Detect DirectX mode, and update its window accordingly, notably by showing it, and moving it at front, 60 times a second.
2.5 Popup over another popup, and again, and again…

It is common that a new (Comodo) popup window is displayed over a previous one before we ever had the time to answer to the first one.
Sometimes, both windows are about the same application, and sometimes about different applications.
Rather frequently, an application can generate dozens of popup (when they use dozens of threads, for example), sometimes quicker than our capacity of reaction.

My suggestions:

* Display only one popup, with a combo list of the requests, and a combo list of the applications (or processes).
* Change some colors in the popup when adding a request, making this addition clear.

2.6 Application requests abstract

An important suggestion.

Let’s see an example:
When an application updates itself, many of its executable files (which will produce processes at run time) are modified.
Comodo, for security reasons, consider them as new files, not related with the previous one. That is the reason why it displays popup windows again at application start (something new and unknown must be checked by user).

My suggestion:

Build an application security requests declaration form. A description of all security requests of the application, by process. This file will be made by the application’s editor/author.

It could be an XML file containing this kind of information:

* AppStart.exe : requests reading and writing files *.TXT, in the user document directory or sub-directories.
* AppStart.exe : requests running AppThumbs.exe, inheriting security context.
* Update.exe : requests modification of *.*, in the application directory and sub-directories.
* Update.exe : requests reading ftp://ftp.thissoft.com/updates/*.*.

This file should be promoted as a standard format, and be used by all security software (anti-virus, firewall, etc) and software creators.
Of course, this file should be protected against third-party modification by a hashing method. By the way, it would be a good place to include a hashing of all files of the application.


* Comodo can display all requests of an application in one page, making very easy to the user to accept or refuse anything he wants, and seeing all requests at once.
  So no more popup windows at application launch.
* When the application updates, Comodo can display the same kind of requests page; but adding information about updated files/processes; and new, old or removed requests.
  So no (other) popup windows at application update.
* Preventing application to modify anything out of its authorized areas.
  It won't be able to modify any other applications' files, nor the registry (except in its area), etc..
  Again, without any popup window (except the one-time main abstract).


Some applications could request the right to modify document files in any directory, but only when approved (by popup) by the user.


  AppStart.exe : requests approved reading and writing files *.TXT, in directory / or sub-directories.

2.7 Fake names

It is very easy for an application to fake the name and some other informations of a safe application.
Against that, fortunately, Comodo tell us if it recognizes the process or not, mainly using an authentication information included in the application’s executable file.

But many executable files do not include this information (mainly because of the complicated and expensive method). That is why we see “Unknown origin” so often.

My suggestions:

* Comodo could, at least, indicate where is the file. In an application's directory (which one) ? In a temp directory ?
* Is there another file with the same name somewhere else, but authenticated ?
  That should be a good clue of a fake.

That is an area of uncertainty, so Comodo should mix several methods of authentication, and deliver a mark, just like an email application can evaluate spam.
2.8 Advanced user rules

When a Comodo’s popup window appears, we only have a few choices.
There are situations where we would like to answer a detailed rule.

Examples of rules:

* Give the <selected authorization> to these processes : C:\program files\the prog\*.exe
* Restrict Internet access to these ports: 80, 220/22F.

My suggestions:

* Add an advanced area in the popup, with possibility to select predefined extensions: name of executable with jokers, list of directories, etc..
* Add a button to display the entire application's page of authorizations I discussed above, with the current entries colored (as an help).

The aims are:

* Avoid many popup windows appearing in some circumstances.
* Improve security by restricting authorizations more precisely (although easily).

2.9 When an application is updated

When an application is updated, many of its files are modified. I remarked Comodo sees these files are new and not related with the previous one.
Although it appears to be a sane security concept, it causes many popups again.

These popups are not that pertinent as they may appear, because after an update, the user does not really knows the new files.
For example, some files could have been modified, after the update, by a malicious software. Anyway, there is no guaranty of sanity.

My suggestion:

When Comodo detects an executable file modification, it should not display an ordinary popup window, but a complete application digest, including all executable files of the directory and sub-directories of the application, and ask the user if they are trustful or not. If yes, all previous authorizations should be transferred to the new files, at one time.

Again, that is tied to my discussion about the Application security requests.
Here, we see that if this list of requests is not furnished by the application’s author, Comodo should be able to create it from scratch, under the control of the user.

3 Specific to Comodo
3.1 The non-automatic « Installation Mode »

When we install an application, usually by running a “Setup.exe” file, a Comodo popup window allows us to select the “Installer/Updater” rule.
So, why Comodo asks us if we want to enter an “Installation Mode” ? Of course, we are installing something, obviously !!
When the application is installed, why do we have to change manually Comodo state to “Previous mode” ?
Why Comodo is not able to understand that the installation is only tied to “Setup.exe” ? So when this process (and all its child processes) is terminated, Comodo can automatically move to “Previous mode”.

Another question, for a possible security breach:

I assume that the “Installation mode” makes Comodo accepting more potentially dangerous behaviors of any running applications/processes. Because, on the other hand, if Comodo was able to restrict this mode to “Setup.exe” (and to is child processes), it would not need to ask us about entering and quitting these modes.

If I am right (and I hope I am not), any application running when Comodo is in its “Installation mode” can break more security rules.
Is it true ?

My suggestions:

* Comodo should tie the « Installer/Updater » rule to its internal « Installation Mode », without prompting uselessly the user.
* Comodo should make inherit the authorizations and restrictions of “Setup.exe” to all of its child processes.

Again, inheritance is an important question for security, and should be managed adequately.
3.2 After a Comodo update, please build again all the rules !

When Comodo updates, it loses your previous choices:

* The “Predefined security policies” you ever created are completely lost.
* The “Computer security policies” are (usually) still listed, but for unknown reason they are not effective, so you have to answer (again) to many popup windows after update.

My suggestions:

* Do not delete users' “Predefined security policies”.
* Apply the requests declaration form I discussed above, in order to avoid useless popups.

3.3 Although you already checked “Do not ask again”, Comodo asks again !

For mysterious reasons, Comodo often ask many times the same question: with the same process ID, same reason invoked, exactly same circumstance; and even a few seconds after the first popup.

I don’t know the reason, but I presume the circumstances causing the two alerts are slightly different internally, but the popup message describes only a part of this circumstances.

My suggestion:

If I’m right, I suggest to not compare internal (and detailed) circumstances, but compare the informations furnished to the user. So user will never read twice the same message (if he already answered “Do not ask anymore”, of course).

More precisely, when the user checks “Do not ask anymore”, Comodo memorizes all the informations of the popup (name of process, type of authorization, user selection), but nothing more. And when the next alert is coming, Comodo compare this information, and nothing else.

Has been suggested before. I feel this is a minor issue.

Not sure if this has specifically been requested, but it is similar to the one above.

Sure, but what happens if a sub process happens to be performing an action you do not want it to do. There would be no way to stop it. If I remember correctly, by putting Comodo in “Installation Mode”, you will not receive those prompts.

Also ties into the one above, and although I agree, if Comodo is setup properly you will receive a prompt before executing the bat file… even if CMD.exe is allowed.

The first bullet has been suggested.


I don’t like your solutions, but I agree with the problem

If a program modified another program/file, the resulting program/file IS a new program/file. Either way, your suggestion seems to only solve the multiple popup problem…

Agree with the first point, displaying the full path to the file, but the second point is kind of pointless if you have the full path to the file.

Has been suggested.

LOL, first, who in their right mind knows every file of every folder on their computer, including the size, name, extension, etc. No offense, but showing the user all the files in the folder would be absolutely pointless.

Second, that method is so complex that every user will just click “yes” without even taking a second to look at the files.

The general concept of detecting when the installation is over has been suggested before. I’m not sure what the specific differences are between “Installer/Updater” and “Installation Mode”, have to ask a dev about that, but there is obviously a difference between the two. So, I would say no to your fist bullet, and I already talked about the second bullet above.

Bullet one has been suggested, and yes it’s annoying… but it doesn’t happen all the time.

I talked about the second bullet before.

You must compare internal details, how else would you determine if the process applies to the already defined rules or not?

I’m not aware of what Comodo compares and does not compare when you tell it to remember your choice. From simply using the program, it doesn’t seem Comodo is simply comparing name of process, type of authorization, user selection only.

The difference is the way it is instantiated.

If you enter installation mode from the GUI, it is a global setting. It will stay “On” until you tell it to return to the previous mode. If you are going to be installing a lot of software at the same time, (well, one after the other obviously…) this would be a convenient way to do it. Just install everything and revert to previous settings after you are finished.

If you treat something as an installer/updater, it will enter installation mode for that particular application only. Any other concurrent processes will be dealt with by your previous modes policies. It is also a temporary mode, in that after you enter installation mode, a timer is started. 5 minutes later, you will get a reminder asking if you wish to return to the previous mode. You also have the option to “Remember” the installer/updater option which can be useful for automatic updaters.

Hmmm… well that explains it. Thanks :smiley: