Protected folders not protected after download of any EXE (V3.12.111745.560 X32)

Environment: Win XP Pro SP3, X32, no other security software running
CIS: V3.9.95478.509 X32, fresh install (not upgraded), Proactive Security
Defense+ Settings menu: Clean PC Mode, Protected Files/Folders checked under Monitor Settings tab
Image Execution Control/Files to Check: *.EXE and *.XPI but not *.ZIP
Computer Security Policy for firefox.exe: Custom Policy, Default Action for Protected Files/Folders = Ask, Allowed Files/Folders = none (initially)

Bug scenario:
After I download an EXE file with Firefox to a non-protected folder, *.EXE is added to Allowed Files/Folders under its Computer Security Policy for Protected Files/Folders. I don’t expect this.
Nothing is added to its Allowed Files/Folders when I download a ZIP file. I do expect this.
The bug is 100% repeatable on my PC.

Implications of bug:
Defense+ fails to alert/block on future writes by Firefox to protected folders with EXE files.

These downloads did not produce any alerts, which I believe is correct because they were not downloads to protected folders. But CIS is acting like I responded to an alert with Remember…

I suspect that the different behavior for the two extensions is related to the fact that only one of them is included in Image Execution Control/Files to Check. However, the unexpected behavior occurs regardless of whether Image Execution Control is set to Aggressive or Disabled.

Edit: Updated the subject with the latest version of CIS where the issue was observed.

I confirmed the same unexpected behavior on both the admin and limited accounts on my PC.

This behavior looks Firefox specific.

Executables are actually downloaded from termporary .part files that FF creates before the download is completed. (downloading test.exe will cause the creation of test.part first)

Adding *.part to D+ executable protected group will trigger an alert at the creation of XYZ.exe.part;msg283578#msg283578

I realize that the statement above is wrong. I expect an alert for Firefox writing an EXE file because the My Protected Files|Executables group includes *.EXE and Firefox’s Default Action for Protected Files/Folders is Ask. Thanks to Endymion for the link that helped me understand this bug better. I really like the quote in the signature too!

Since the Comodo forum requests one bug per thread, I created a new thread for the no-alert bug:

The topic of my first post in this thread is the bug where D+ modifies the Computer Security Policy without the user selecting Remember on an alert.

*.exe learning is a side-effect of a more general behavior in relation to Firefox scenario.

My current work-around for the bug, where D+ modifies Firefox’s Computer Security Policy without the user selecting Remember on an alert, is to change the default action to Block for Protected Files/Folders, and add C:\Downloads* to the Allowed Files/Folders list. This restricts Firefox to only download executables to the C:\Downloads\ folder.

Since I added *.XPI to the D+ Executables group to prevent Firefox extension installations by the limited user account (LUA), I have to manually change the default action to Ask when I, as the admin, want to install Firefox extensions. Then I have to remember to change the default action back to Block. If the bug did not exist, I could just leave the default action as Ask. With Parental Control enabled, the LUA gets default deny for the alert triggered by installing an XPI, while the admin can choose allow for the alert.

As the title is generic enough please test your scenario in D+ paranoid mode (which disables safelisting) too.

This testcase specifically address firefox which is a safelisted application despite the scenario results are inconsistent with usual protected folder behavior.

As safelisted application are allowed some autolearning there is no information yet about what makes Firefox different from other safelisted applications that trigger alerts when creating new files.

Did you delete Mozilla Corporation from My Trusted Software Vendors list under Defense+.

(Even if you have instructed CIS not to trust any software vendors, I would still suggest deleting it from the list, before testing it).

AFAIK, in previous versions of CIS I exactly do not remember whether it is after CIS or in CPF 3.0, there were lots of people complaining in this forum, as to why Defense+ alerts when Firefox opens a file under a folder since it is a safe application. I don’t know whether it has anything to do with it, as the lots of users commented against this behaviour as it was supposedly giving them unnecessary troubles for simple things. I think CIS has since been concentrating more on user friendly ways, as Melih himself has opened a separate topic asking whether CIS has now been more user friendly or not, after release of the new versions of CIS.

I don’t know what changes were done by you in the CIS to ‘personalise’ it. I just tried your scenario in my CIS, which is default CIS without any tweaking on my side except Defnse+ in proactive security.

In order to test your scenario, I did the following :

Open CIS>Defense+>Advanced>Computer Security Policy>Firefox.exe
Double Clicked Firefox.exe, which opens the window Process Access Rights

Changed Physical Memory, Disk and Keyboard to (Ask) Rule from existing ‘Allow’ Rule

Tried to download an exe file using Firefox and immediately CIS alerted saying Firefox is trying to open a file/folder (something like that). I blocked it. To my amusement the file was able to download but could not finish it and ended with an error message. The file now shows filename.exe.part (not recognised by windows), which means the file is no longer able to do anything.

(In other words, on CIS’s own way it blocked the file from doing its job, though I would have been more happy if it was not able to do download at all. But, as I didn’t do much tweaks, so I am not sure whether this can be done or not as Firefox in itself is a trusted vendor for me in CIS! To me CIS not only alerted me but also blocked the file)

I tried to manually change the downloaded exe.part file and again I got an alert from CIS for it. I blocked it and the file was not able to rename it as an executable.

Hence, I feel CIS is capable of meeting the needs of advanced users. (I didn’t configure CIS for this much security, though I use proactive security to meet any eventualities of critical nature).

I hope the above is self-explanatory, which can be tested on your side. (Hopefully I understood your query in a proper way).

You must have been in paranoid mode or it would not allow this. I think safe or clean PC mode is required for it to add *.exe to allowed files which is the problem under discussion.

If you block direct disk access you get a pop-up for ordinary disk access but it is not blocked if you try to block it. This could be what is happening here as it tries to save the .part file.

Defence+ must be blocking the renaming. I have never seen this, but I do not use paranoid mode.

Mozilla Corporation is in My Trusted Software Vendors list because I installed CIS (using Clean PC Mode) after Firefox. I have never removed Mozilla Corporation from the list.

I didn’t customize the access rights of Firefox - they are at the default for apps on the Comodo Safe List (allow everything except Ask for Protected Files/Folders and Protected Registry Keys).

Your different access rights establish a different scenario, but still useful evidence. Also, are you using Clean PC Mode?

I have seen Allowed Files/Folders change to *.EXE after using another application to copy one EXE file, but there is always an alert for the first copy. I am trying to document a reproducible scenario. This evidence establishes that the bug is not limited to Firefox, and that non-alerting and this bug are separate bugs.

As there is always an alert for the first copy could it be you are misinterpreting those evidences?

I tested with the FreeCommander application, available at Downloads
I am not sure if FreeCommander.exe is on Comodo’s Safe List because I installed it before CIS with Clean PC Mode.
I use Defense+'s default access rights for a trusted application: Allow for all, except Ask for Protected Registry Keys and Files/Folders.
Let TestA = C:\WINDOWS\system32\mspaint.exe
Let TestB = C:\WINDOWS\system32\notepad.exe
Here is a scenario to reproduce the bug:
a. In FreeCommander, copy TestA, paste to the C:\Downloads\ folder
b. Response to Defense+ alert: Allow WITHOUT Remember My Answer
c. In FreeCommander, copy TestB, paste to the C:\Downloads\ folder
d. Response to Defense+ alert: Allow WITH Remember My Answer
e. In FreeCommander, click on C:\Downloads\TestA, press Shift-Delete (deletes without going to Recycler)
f. Go to CIS|Defense+|Advanced|Computer Security Policy|double-click FreeCommander.exe|Access Rights|Protected Files/Folders|Modify|Allowed Files/Folders
g. Observe two items listed: C:\Downloads\TestB and *.EXE

If you observe the Allowed Files/Folders between steps d. and e., you will see C:\Downloads\TestB but not *.EXE.
Since there was no “Remember My Answer” in response to the alert for TestA, I don’t expect anything in Allowed Files/Folders for it.
Even worse, the FreeCommander application will not produce Defense+ alerts for writing any .EXE file in the future, including to folders in My Protected Files!

I propose that this scenario is an easier to understand and debug than with Firefox due to Firefox’s complex download.
Since there were no initial missing alerts, this is a separate bug from this one:

I reproduced the bug with a similar scenario as my last post, but using Windows Explorer instead of FreeCommander. This eliminates the need to download a new application for testing.
Go to CIS|Defense+|Advanced|Computer Security Policy|double-click explorer.exe|Access Rights, and change the default action for Protected Files/Folders from Allow to Ask.

Users of CIS V3.9.95478.509 potentially have *.EXE, *.COM, etc. allowed for the access rights of many applications with a default action of Ask, which is the default for safe/trusted applications. When users update CIS to a version with this bug fixed, maintaining the same Defense+ Computer Security Policy rules would carry forward the trained security flaws. I propose that Comodo offers a means of removing the *.EXE, *.COM, etc. exception rules, either as a separate tool or during the update.

I would appreciate inputs from other users stating if they reproduce the bug or not with any of my scenarios, including their operating system and Defense+ Security Level.

I just tested to see whether CIS could actually alert or not when a file is downloaded using Firefox that’s all, to check whether it is true that Firefox can download anything without my intervention. With the small changes as mentioned in my earlier post, CIS actually alerted me and in my opinion it also blocked it from being active, though not giving permission to download at all would have been better.

I have never used paranoid mode. I was content with ‘Internet Security’ mode for a long time, till some of the posts in the forum pointed out that it fails some leak tests, which are potential enough to be used by exploiters. Now I use Proactive Security but no tweaks were done to rules already created in Defense+ when CIS was in Internet Security Mode. And I am happy with this setting.

Free commander and firefox are in the safe list. As soon as any safe application is allowed to write to one exe it is allowed to write to any exe. That appears to be the way it is designed.

I have complained about this blanket allow for safe applications many times. The answer is always use paranoid mode which is unusable for me.

I have suggested a solution to all these problems in my post:

This would allow users some control over so called safe applications without all the pain of paranoid mode.

What part of it is a bug? And what would be the behavior you expect considering that all your scenario involve Safelisted applications in Modes that enable learning for safelisted apps (the main reason safelist was created)?

Yep there is no pseudo-paranoid mode.

Indeed in paranoid mode the specific path is specified and wildcards (*.???) are not used.

In paranoid mode the user can choose what default policy (including custom made predefined policies) apply to applications even if it is mentioned they are safe-listed as soon they get an alert

Thus using custom predefined polices with a single click they can choose if allow all actions or only part of them, they can choose what they should being asked for and what should be automatically blocked too.

The user would have the highest degree of control over any application if s/he really wish so.

I just repeated testing my scenario above with the following changes:

  • For the alerts on both TestA and TestB, I responded with Allow and “Remember My Answer”

The Allowed Files/Folders list now contains the exact path and file names of TestA and TestB (in the C:\Downloads\ folder). In other words, there is no *.EXE entry.

I also repeated testing my scenario above with the following changes:

  • For the alerts on both TestA and TestB, I responded with Allow and “Remember My Answer”
  • I used unsafe files (not on Comodo’s or my own safe list) for TestA and TestB

Again, the Allowed Files/Folders list now contains the exact path and file names of TestA and TestB (in the C:\Downloads\ folder). In other words, there is no *.EXE entry.

Thus, D+ allows *.EXE only if I deselect “Remember My Answer”, regardless of if the .EXE written is safe or not.

Why I think the scenarios in my previous post are bugs?

  • D+ allows more when the user deselects “Remember My Answer” than if he/she selects “Remember My Answer”.
  • When Ask is the user or default action, the user doesn’t expect that unsafe EXEs are allowed in the future.
  • When the user allows an EXE copy/download, the user doesn’t expect that protected folders are now unprotected.

This is actually an indirect observation about what may happens on file operations for some safelisted applications.
Although the behavior could be unexpected it may not always due to a bug (although in some case users could be willing to call bug something they don’t like)

About what user expect it looks like that there are many that are not willing to see any alert for safelisted applications.

The testcase implicitly legerage on safelisted application autolearning although this is something neglected in the topic title.

Adding wildcarded exceptions to protected file folders (eg *.exe) happens due to autolearning of My protected files - Executables list (CIS proactive config). As such this aspect should be expected.

Despite the action visible to the user may be a seemingly simple one (eg copy) this doesn’t mean that the applications won’t carry multiple actions that pertains protected file folder access right nor the GUI provide a way to identify subcategories for protected file folder access right.

Autolearning is not enabled for all of these actions. In case an action that trigger autolearning is carried first this ought to mean that the File folder access right get modified and an exception added. Disabling this mean triggering alerts for all types of actions pertaining protected file folders.

Although safelisted applications are involved there would still be Run an Executable and AV layer.

To have full contol over the access rigts and behavior paranoid mode would still be the best option.

Paranoid mode maximize the span of protection and don’t use automatic learning for safelisted applications and AFAIK use full paths (although it looks like this is a characteristic of alert marked to be remembered).