Comodo Internet Security v11.0.0.6606 - Released

[Citizen K]

In daily use, is there a possibility that users will face such mentioned risks above? Such as just enable paranoid mode of HIPS and disable Sandbox.

This is a user bypass.

I think the HIPS is still path based like in the old days and not hash based so users are allowed to do smart and not so smart things. You are mentioning Paranoid Mode and HIPS only. They are not default settings and require users to be knowledgeable. CIS has always been the nanny of program behavior and not the nanny of user behavior. For which I am very happy.

If you want to work hash based keep the auto containment switched on. Most of the users don't want to tinker with a security program. They are in safe hands with hash based auto containment.

[futuretech]

Someone questioned the updated list item below in China, and pointed out a serious bug.

Because he could produce this issue by following steps.

Steps:
1. Disable Containment, enable HIPS.
2. Run an unknown exe file(file A, he has a file named filetest.exe in his test). It was blocked by HIPS when trying to write a file into protected directory.
3. Change this file to "trusted" in advanced setting manually, the OK to close.
4. Delete this file in windows explorer.
5. Copy another exe file(file B) into this folder and rename it to has the same file name as the deleted one. So the new exe file has a same file name with the original deleted one.
6. Run this new renamed file.
7. Check the file detail, you may see that the new file has a same sha1 with the original one.

It's terrible if the new file is malicious, but COMODO treats the renamed file has all the same privileges as the original one. In another words, it can do the same operation just as the original one.

Couldn't replicate, I even tried deleting an already trusted file and moving a different application of the same name to the previous deleted file location, once I tried executing, HIPS warned of the new application.

[Redstraw]

Couldn't replicate, I even tried deleting an already trusted file and moving a different application of the same name to the previous deleted file location, once I tried executing, HIPS warned of the new application.

Check their sha-1 in comodo file details to confirm whether they are same or not.

[Redstraw]

Please try to achieve same via some unknown application rather manually replacing file as manual operations are done more in context of Windows safe apps.

I will tell him to test just like your requirement.

Personally, another question,  can you confirm that comodo recognizes both files have a same sha-1 in this kind manual operation?

[Citizen K]

The question is rather whether the HIPS uses hash check or not. I am not 100% but don't think it does.

[Redstraw]

The question is rather whether the HIPS uses hash check or not. I am not 100% but don't think it does.

Start with the phenomenon first, then deeper.

[ZorKas]

Hello,

Congrats Comodo team on the new release 



ZorKas

[pmikep]

So, it might be that HIPS has always been this way. But since CIS v11 is out, I'll make an official pseudo-issue report:

When I open a complicated program for the first time after installing CIS, like Dragon NaturallySpeaking, I sometimes have to open the program twice before all the "Intrusions"/Rules can be set.

I should make a video to show this. But, for example, when I started Dragon, I got a few HIPS popups and I Allowed them all. But Dragon never opened, even after the pop ups stopped. I checked TaskManager and it said that Dragon was running. But I had to open Dragon a second time. Then I got a different set up pop ups. After I allowed all of those, then Dragon ran normally.

I dunno. Maybe this HIPS stuff is very complicated with processes spawning other processes that don't start right if the user doesn't acknowledge a pop up fast enough. Or maybe there's a buffer size for HIPS queries that's not large enough? Or maybe processes collide and lock themselves out? (WAG's, all.)

Anyway, thought I would report it. I'm a seasoned Comodo user (10 years +) so it didn't faze me too much. But I can see first timers getting confused and blaming the product.

[prodex]

I can confirm this. But no reaseon not to use comodo. I installed cis11 several times and over and over I went back to cis 10 which runs without issues as far as I'm concerned.
What you wrote is the reason, too, why I didn't tell of the problems because I weren't able to discribe them exactly as requested in the form.
I'll wait for the update later next week which is not an offline installer (don't know how to say it in English - it's the automatic installing).

Can version 10 furthermore be used as a software which protects me or is it then a vulnerable version if I want to stay at version 10?

But since CIS v11 is out, I'll make an official pseudo-issue report:

I dunno. Maybe this HIPS stuff is very complicated with processes spawning other processes that don't start right if the user doesn't acknowledge a pop up fast enough. Or maybe there's a buffer size for HIPS queries that's not large enough? Or maybe processes collide and lock themselves out? (WAG's, all.)

Anyway, thought I would report it. I'm a seasoned Comodo user (10 years +) so it didn't faze me too much. But I can see first timers getting confused and blaming the product.

[Umesh]

Hi pmikep,
If you think it's a regression, we will appreciate if you could please file a fully qualified bug report as suggested here.

We will need all details like OS, steps, CIS configuration.

Thanks
-umesh

So, it might be that HIPS has always been this way. But since CIS v11 is out, I'll make an official pseudo-issue report:

When I open a complicated program for the first time after installing CIS, like Dragon NaturallySpeaking, I sometimes have to open the program twice before all the "Intrusions"/Rules can be set.

I should make a video to show this. But, for example, when I started Dragon, I got a few HIPS popups and I Allowed them all. But Dragon never opened, even after the pop ups stopped. I checked TaskManager and it said that Dragon was running. But I had to open Dragon a second time. Then I got a different set up pop ups. After I allowed all of those, then Dragon ran normally.

I dunno. Maybe this HIPS stuff is very complicated with processes spawning other processes that don't start right if the user doesn't acknowledge a pop up fast enough. Or maybe there's a buffer size for HIPS queries that's not large enough? Or maybe processes collide and lock themselves out? (WAG's, all.)

Anyway, thought I would report it. I'm a seasoned Comodo user (10 years +) so it didn't faze me too much. But I can see first timers getting confused and blaming the product.

[ZorKas]

I had quit CIS for problems from earlier versions
Today I find CIS with a significant advance
Thank you to the team 
cordially

ZorKas

[Citizen K]

Start with the phenomenon first, then deeper.

Nope, start with the assumption that it is the job of CIS to protect the user against tinkering with non default settings. CIS is the nanny of program behaviour not the nanny of user behaviour. Thank God for that.

[Citizen K]

So, it might be that HIPS has always been this way. But since CIS v11 is out, I'll make an official pseudo-issue report:

When I open a complicated program for the first time after installing CIS, like Dragon NaturallySpeaking, I sometimes have to open the program twice before all the "Intrusions"/Rules can be set.

I should make a video to show this. But, for example, when I started Dragon, I got a few HIPS popups and I Allowed them all. But Dragon never opened, even after the pop ups stopped. I checked TaskManager and it said that Dragon was running. But I had to open Dragon a second time. Then I got a different set up pop ups. After I allowed all of those, then Dragon ran normally.

I dunno. Maybe this HIPS stuff is very complicated with processes spawning other processes that don't start right if the user doesn't acknowledge a pop up fast enough. Or maybe there's a buffer size for HIPS queries that's not large enough? Or maybe processes collide and lock themselves out? (WAG's, all.)

Anyway, thought I would report it. I'm a seasoned Comodo user (10 years +) so it didn't faze me too much. But I can see first timers getting confused and blaming the product.

Can you see what happens when you add the executable of Dragon or its installation folder to the Exclusions of Disable shellcode injection detection (i.e. Buffer overflow protection)? It may help point the finger in the right direction of where the bug might be.

On a side note. I remember that years ago another user had a problem with Dragon Natural Speaking. It's been a long time I have seen that name pop up here.

[pmikep]

Another "issue" with CIS that has been around for a long time. (Since v6.) This might be intractable, since, in a sense, HIPS is doing exactly what it's supposed to do. Here's the issue:

I just updated some drivers. Some installers/updaters - like those from RealTek, use an old fashioned DOS like installer from Windows 3 days. The installer requires a reboot to finish installing the new driver. (Since it uninstalls the old driver first and has to reboot to clear out old startup stuff and/or to release the old drivers from use.)

So when the Installer finishes part One of the install, and while Windows is shutting down, I hear a ding sound as HIPS detects something trying to run. Like, maybe the "restart the installation after reboot" command? (I don't know because it happens so fast, and Windows shuts down so fast, that I can't see the CIS Alert.)

I also get this behavior after installing Nvidia drivers. Apparently there's something that Nvidia wants to do to its "Container" when Windows is shutting down.

On days when I'm smart, I've learned to set HIPS to Disable when installing new drivers. (Although that's not very satisfying, because some companies try to sneak other stuff in during an install.) On days when I'm not smart, I have to restore a previous image and then try to be smart during the install.

I think there's a Registry Hack that will delay the Windows Shutdown process. If so, perhaps CIS could invoke that (as an option?) whenever an HIPS Alert pops up during the Shutdown sequence?

[Citizen K]

Another "issue" with CIS that has been around for a long time. (Since v6.) This might be intractable, since, in a sense, HIPS is doing exactly what it's supposed to do. Here's the issue:

I just updated some drivers. Some installers/updaters - like those from RealTek, use an old fashioned DOS like installer from Windows 3 days. The installer requires a reboot to finish installing the new driver. (Since it uninstalls the old driver first and has to reboot to clear out old startup stuff and/or to release the old drivers from use.)

So when the Installer finishes part One of the install, and while Windows is shutting down, I hear a ding sound as HIPS detects something trying to run. Like, maybe the "restart the installation after reboot" command? (I don't know because it happens so fast, and Windows shuts down so fast, that I can't see the CIS Alert.)

The logs can tell you what the alert was after the reboot.

I also get this behavior after installing Nvidia drivers. Apparently there's something that Nvidia wants to do to its "Container" when Windows is shutting down.

Do you still have the auto containment on? C

Could you check the logs and see with the installation of the Realtek and Nvidia drivers whether the alert you got was from the HIPS or autocontainment?

On days when I'm smart, I've learned to set HIPS to Disable when installing new drivers. (Although that's not very satisfying, because some companies try to sneak other stuff in during an install.) On days when I'm not smart, I have to restore a previous image and then try to be smart during the install.

I think there's a Registry Hack that will delay the Windows Shutdown process. If so, perhaps CIS could invoke that (as an option?) whenever an HIPS Alert pops up during the Shutdown sequence?

These days I work with HIPS only because I find auto containment too intrusive in situations similar to what you describe.