I am a software developer using Microsoft Visual Studio with C/C++. Obviously I write source code and it creates EXE files which change all the time.
I tried out CIS v6 soon after it was first released. Ok, so the interface is ■■■■ and is being worked on as we speak, BUT…
In v5, you can add a special rule to the “Defense+”-“Computer Security Policy” for EXE files which are constantly changing because they are being generated by the compiler. Comodo complains every time the EXE is run, so you could add a rule labeling the EXE as an “Installer or Updater”.
This basically informs Comodo that the EXE is safe even if it’s checksum (MD5 or whatever) changes.
Note: Yes, I reverted back to v5 due to this huge problem.
In v6 I tried exactly this same trick and also looked for another alternative way of achieving this, but to no avail. This “loophole” seems to have been removed in v6.
My Question: Has the current v6 (i.e. v6.1.275152.2801 I think it is) have a way to flag specific EXE files (and DLL’s for that matter) as safe (i.e. as a developers EXE or something) no matter what happens to their checksum?
Thanks for listening. I did a search before posting and could not find any topic about this.
See if using the Windows System Application policy does the trick instead of the Installer/Updater.
Just to be complete. You did move the rule for the executable to a place above the “All Applications” rule in case the “All Applications” rule is present?
Yes, I believe that the rule was the first one in the list above all others.
I am currently using v5 and really don’t want to go through the LONG process of un-installing v5, then installing v6 just to see if the “Windows System Application policy” may work. That’s one reason for asking the question in the first place.
I has been a while, but I am almost sure that I tested ALL the available policy types.
One comment: Aren’t there other developers out there using Comodo v6? They must have the same problems as I do.
I must admit that I have setup the “Unrecognized” behavior to “Untrusted”. So in effect I have to run any unknown or changed EXE twice before it can run at all.
Even worse are IDEs that use temporary, randomly named batch files to execute compiler tool chains. Every time one is used, the .bat file is a new program to allow to run(1st alert)… then even though the compiler .exe is trusted, the randomly named .bat file(parent) is not, so that generates another alert(2nd alert). I run into a lot of Java programs that do similar things and are a huge pain to make rules for.
If I give up and use Game or Training mode I’ll end up with a few dozen entries of “dead” .bat files to be purged later. All in all, the Installer profile not working as it did in v5 is a big pain.
Visual Studio with C# isn’t terrible as long as you allow your project to use the VSHOST parent process. Where a static .exe file loads your newly compiled program as an assembly and executes the code internally. Comodo doesn’t seem to think that is an issue since there is no new process run.
RE: EricJH’s suggestion… I’ve seen it a few times now. Why is this a supposed fix to begin with? As I understand it, the Windows System App policy is a combination of Allowed Application and the ability to execute any child application. Furthermore, the Installer/Updater policy is a combination of the Windows System Application policy and the ability to pass that policy to the child processes it creates. From what I’ve seen, the WinSysApp and Installer policies are equal… child processes are not inheriting any policies like they should.
If you can reproduce that please submit this as a bug report in the bug report section. I had already noticed something was up with the Installer/Updater policy.
I’ve wanted to write my own program to probe against this issue in a clean-cut manner since I have a couple machines with v6 and another couple with v5… but… I keep getting distracted and I only think of it when it pops up and annoys me again. :-\
Okay, I made my testing program and I think I conclusively figured out what the supposed bug introduced into v6 is.
Little disclaimer: This is what I assume these terms mean… Allowed Application: Allow any protected action except spawn new processes. Windows System Application: Allow any protected action including spawning a new process. Installer/Updater: Allow any protected action, spawn new processes, new processes temporarily inherit the Installer/Updater policy.
Expected functionality:
Process 1 is given the Installer/Updater policy
Process 1 is able to spawn process 2; process 2 inherits the Installer Updater policy
Process 3 is given the Windows System Application policy
Process 3 is able to spawn process 4; process 4 has no policy and is protected against
Process 5 is given the Allowed Application policy
Process 5 cannot spawn new processes
As a side note, if a parent process with the Installer/Updater terminates… child processes, and by extension their children, may lose the inherited Installer/Updater policy. Under v6, if a parent terminates the child immediately loses the inherited policy; under v5 this wasn’t always the case but the chain would fall apart eventually. I couldn’t nail down the exact logic but this is just an extra.
Now to the actual “bug”. It’s actually quite simple if unexpected. When you first give a program the Installer/Updater policy, everything detailed above works properly. If you close the program and re-open it, its policy mimics Windows System Application even though it clearly shows Installer/Updater in the HIPS Rules. So the Installer/Updater policy only works for one execution regardless of saved rules.
If you manually add a rule through the UI instead of the alert dialog, the Installer/Updater policy will not work even once. It will immediately behave as though it is given the Windows System Application profile.
This is BRILLIANT! Thank you “jljtgr” so much for spending time to investigate this.
I didn’t think that it was actually a bug, just that code had been deliberately removed or “fixed” to stop the loophole of allowing a rule to be created on a specific EXE or DLL which could therefore be a potential security risk. So I thought it was actually intentional. Obviously that is NOT the case.
Since a bug report has been submitted to Comodo, then hopefully it will be fixed in the next release.
This is the primary reason that I don’t update to v6.
Have software developers been supported in Comodo HIPS v6 yet?
I don’t want to go through the LONG procedure of installing v6 to find out that the HIPS still hasn’t been fixed.
Yes, I spent about 2 hours searching this forum for an answer on this before asking a new question.
I don’t entirely understand what your situation is however I made a video that goes through a situation with executables that change, if it isn’t what you’re looking for then could you perhaps go into more detail of your situation so I can look for other ways to deal with that?
Edit: Video removed for the time being, working on another one, sorry about the inconvenience, it will be back soon (within an hour)
Edit 2: New video is here: How to allow changing applications for HIPS & BB in CIS - YouTube (still processing) Sorry about the length.
So basically as I understand it you want to be able to allow an executable, lets say test.exe, and you want it to still be allowed if the code inside it changes? You could achieve that for HIPS by making an application rule for it, and you could achieve it for BB by making an exclusion, I go through how to do that in the video. I also go through how to do that for an entire folder if you have many executables.
Thank you very much “Sanya IV Litvyak”! I really appreciate the time you spent creating the video.
In fact the biggest problem was the behavior blocker. I have it set to “Untrusted” in v5, so basically I have to run whatever application (EXE) which was created newly by my compiler twice to get it to work properly.
Using the detailed description you made in your video I am confident that I can now upgrade from v5 to v6 and get it all to behave properly and without drama.
The v6 I tested was from May 2013 and I think that a lot has changed since then.
Thanks again. I will let you know (via another post here) how I got on.
That’s not quite the situation that is viewed as the bug. The underlying bug has nothing to do with files being modified at all. The parent process(IDE) is set as Installer/Updater, so all other files executed should also (temporarily) be Installer/Updater regardless of them being modified at some point. That is why this policy is being used for IDEs.
To my knowledge, it is not yet fixed, despite them trying to. I don’t know if they don’t understand the issue or the things they’ve tried were not enough and they don’t fully test their changes.
Though reading your newest post… you think you have a way around the bug for your purposes? I haven’t watched the video yet since it’s 15mins.
I don’t think the installer/updater policy has been fixed yet however I believe there are other ways to get around the issue/situation Mainframe was/is having if I understood those issues/situations correctly the issue there is that I didn’t exactly however I decided to make the video just in case it would help him.
I just installed Comodo Firewall v6 with the Firewall, HIPS and Behavior Blocker active.
I added some exclusion rules (only 2 actually) to the Behavior Blocker as described by “Sanya IV Litvyak” in his video to allow me to re-compile the main sections of our product. The Behavior Blocker now happily ignores the changed EXE’s.
This is a HUGE relief as now I am able to run v6 without headaches.
The main EXE of our product, for which I added as an exclusion to the Behavior Blocker, does in fact dynamically load DLL’s (using LoadLibrary()). This activity IS in fact allowed without warning by the Behavior Blocker. I am really happy that it is indeed allowed, but I noticed during the video from “Sanya IV Litvyak” that in v7, this kind of behavior will be monitored and for each exclusion added to the Behavior Blocker, a rule/setting can be added to allow DLL loading (I think that I am right about this). So that will add further security to the Behavior Blocker.
The update from v5 to v6 went fairly smoothly, but ALL my firewall rules (I had a lot of blocked applications) were thrown away, which is a big shame.
I have noticed that the new Comodo slows things down as compared to v5, but not considerably.
v6.3.302093.2976
Using Clean PC mode, the bug still occurs exactly as shown in my example video(in the bug report). Tomorrow I’ll test it again using HIPS in Paranoid Mode when I have easy access to a PC configured to use it.
