Comodo 4.1 still fails with spyshelter leaktests

The screenshot #4 also fails on my tests, quite worrying especially when I do lots of e-banking.

The biggest concern for me is that although sandbox is switched on, the first alert I receive is not the sandbox one, but of antitest.exe asking for com access.

I would also assume that nothing significant can escape the sandbox therefore no screenshots should be possible by antitest. At least that is how I would want a sandbox to operate. And there should be no need to change D+ settings from clean PC mode since this exe is not part of the baseline applications on the PC, simple as that.

The Devs really need to fix this leak since it may have wider implications than just this one test :o

Update #1:
…and just to add 1 day later that the webcam capture also succeeds if the sandbox dialogue box is ignored and it times out naturally. If i manually confirm to keep the exe in the sandbox then webcam does not succeed.

Sorry guys but this seems like insufficient design and especially since as we say in English that comodos “eggs are all in one basket” in that Melih says it is all about prevention not detection :P0l

On the positive side at least the Matsoutec tests results are excellent, but these holes need to be fixed and understood how they happened! Less new features, more quality and design control please guys.

Update 2:
I forgot to mention that on antitest.exe CIS failed also the sound recorder test.

I have since noticed that a bunch of leaktests have been performed recently by malware research group and especially one on financial / banking security by testing specific apps such as Prevx, not generic Internet Security apps such as CIS. Here is the link to the very interesting test:
Prevx came out top scoring 13 out of 13 and had CIS been included it would have got 11/13 according to my tests above, so pretty good, but those holes need plugging! I also noticed that disabling the sandbox produced a clearer control over alerts and gives me higher confidence of preventing leaks than sandbox alone. I also tried the Zemana tests and CIS succeeded in all those that managed to execute.

Also if D+ prompts a user to allow or deny an exe and deny is selected then there should be NO FURTHER EXECUTION ALLOWED of that exe. I tried the keyboard.exe test from Zemana and CIS continued to prompt me with D+ alerts and allowed the application to display!

Interestingly the Malware Research Group has since tried to test generic apps such as CIS but it seems that Comodo may have requested themselves to have been removed since on the product list there is now a black line exactly where alphabetically CIS should be !!! Hey comodo, what’s the story?!
Here is the link:

It looks another member posted a New feature suggestion : Block + Terminate instantly wish in the corresponding board.

The Allow/Deny on alerts apply to the specific action whose security consideration are described.

eg: In case the action is “Run an executable” deny will prevent the executable (whose name is provided on the right half of the dialog) from being launched.

Even if there are much less alerts, some alerts might sitll apply even if an application is sandboxed. In such case the application carried an action for which user input is needed.

Found no way to block Spyshelter Screenshot grabbing PoC N #4. :frowning:

Webcam logging PoCs were tested on V3. The related steps still apply whereas the sandbox is disabled (tested on XP SP3)

Liike the previous one even this webcam PoC cannot access the webcam if used by another application (eg video-chat).

Logging an active webcam video-session could be achived using screenshots or through kernel drivers fit for that purpose.

The PoC in itself apply more to environmental monitoring scenarios whereas the webcam has no lens-cap covering the optics while not in use.

Adding \RPC Control\AudioSrv to “My protected COM Interfaces” it was possible to have Spyshelter Sound recording PoC Fail (tested on XP SP3)

Thanks Endymion. I don’t know a great amount about firewalls, let alone CIS, other than being a Comodo user for a few years and so far knowing / enough to avoid any major malware or leaks.

Since my earlier post I decided to uninstall CIS and then reinstall with firewall plus maximum security. I then disabled sandbox.

For reasons I do not fully understand when I now run antitest.exe and keyboard.exe I am prompted with a D+ alert and when I select block and remember it now fully blocks and the apps to not progress any further. They do not however appear in blocked files list, so am not sure what CIS is doing with them exactly. When I try an run a second time then I actually get a Win 7 system message saying that win cannot access the exe. In task manager antitest.exe is visible but not keyboard.exe.

So it seems this change has effectively isolated the exe files, but I am not clear how, although I do feel more re-assured now.

As I mentioned earlier allow/deny apply to the specific action described in each alert.

Though you did not make mention of what alert you denied it looks like it was a “Run an executable” one with explorer.exe as parent (left side) and antitest.exe or keyboard.exe as child (right side):

Denying such type of alert will prevent explorer.exe to run those executables.

If such alert is not marked to be remembered it will be still enforced as long the parent application (explorer.exe) is running (usually explorer.exe will run until a reboot/logoff)

“My blocked files” is meant to be used differently as described in the help file. In short manually adding antitest.exe and keyboard.exe pathnames to that dialog will prevent any application to launch those executables (eg not just explorer.exe)

Yes i can see from the log it was explorer.exe being prevented from running the target .exe

But what puzzles me is that this did not work before re-installation earlier today. The previous installation was not on the maximum security default and I do not know why the difference occurs.

Anyway, now D+ blocks effectively.

I see. Installing “Firewall with Maximum Proactive Defense+” activated “COMODO - Proactive Security” configuration defaults.

This configuration got an explorer.exe policy that is meant to trigger alerts when explorer launch unrecognized (non safelisted) executables whereas this alert type is triggered when Sandbox is Disabled and D+ is Enabled.

“COMODO - Internet Security” is another configuration seamlessly activated (no multiple choices during install) when both Comodo firewall and AV are installed and probably if “Firewall with Optimum Proactive Defense” is selected whereas firewall only install is used.

With “COMODO - Internet Security” configuration, explorer.exe will get a different policy (along with slightly different defaults) with a rule that will allow explorer.exe to execute also unrecognized applications without triggering the corresponding “Run an executable” alert.

Great explanation and refreshing my misty memory! What you are highlighting is that the full suite default is not as secure as I think it should be. It should not allow screen captures etc by malware !!!

Due to the risk of malware slipping through full CIS with AV i uninstalled and decided to now run just Comodo Firewall in proactive security mode + Microsoft Security Essentials + Threatfire alongside.

Whilst I do not feel fully comfortable using MSE, as a free firewall 88) AntiVirus I prefer it to many others I have tried Avast, AVG, Avira, etc, etc. etc, but they all had important issues. MSE permission to be used in commercial use “home based small business” is also important for me. It also has good reactive detection according to several tests.

It’s worth mentioning that I actually received this laptop 2 months ago with Norton IS 2010 pre-installed but I simply could not relax the firewall to allow incoming connections from my local network from scanners and other devices, plus it was a resource hog. The interface was, I am sorry to say, designed for visually impaired people, with huge bright icons and labels and actually very difficult to navigate and track down exactly where to go to fix an alert or configure something.

Then I installed my commercial licence of Kasperksy 2010 but still faced various issues and performance hits. It is also visually impaired in its design and difficult to troubleshoot issues with it. Seems everyone is happy to dumb-down.

So now I am back to Comodo once again after several months away and one day hope to be 100% comodo once the AV improves and melih allows it to be tested on VB100 and other tests!

Perhaps Threatfire is redundant now that D+ is working well, but there are no conflicts and I guess it could one day save my ■■■ if I inadvertantly allow CIS to let something nasty through! And I guess that’s another issue with CIS, it is highly dependent on rules whereas tools like Threatfire and Prevx have quite a lot of built-in intelligence, assessment and decision making.

Anyway, time for dinner now. Bye.

MSE is not a firewall, just a antivirus. Threatfire will be a thing of the past because a behavior blocker is coming to comodo. Also the AV has improved lots, I would give it about 98% from the malware research I have done. I submit tons of files to virustotal and have a pretty good idea who leads in av detection rates.

Even installing the full suite is possible to activate “COMODO - Proactive Security” configuration defaults (tray icon configuration menu).

And of course each user can choose to change those defaults even further as long their ownership of the suite increase (eg by asking in these forums )

LOL You sound just like me! And I totally agree 100%!

Rog :slight_smile:

If you failed this test it’s because you allowed it to run when you should have blocked it if you didn’t have it running in sandbox or enabled. Honestly all the noobs should enable sandbox by default anyways. There is nothing going to get past Comodo (CIS) except for one’s stupidity.
Errm, no, that’s incorrect conclusion.

The whole issue, at least what I have experienced in my tests after reading about these controversial tests, is that running the standard CIS config which includes sandbox enabled and with all alerts clicked to deny and remember DOES ALLOW access to screenshot (test number 4 on the antitest.exe) as well as access to the microphone. In some cases, depending upon the order which CIS D+ decides to serve up its alerts it even got access to the webcam.

The main point is that with pro-active security config enabled and sandbox disabled DOES PREVENT the leaks from occuring by completely stopping antitest.exe

Comodo need to fix this rather arguing the toss about methodology etc. OK the testing organisation might not be fully credible, but malware writers are not going to follow any standards in trying to hack anyone’s data.

And it does not really help Comodo community to be so arrogant and to mock newbs. Please remember that everyone was once a newb. And we have all been stupid at some time, hence the need for good software like CIS; it just needs tweaking a bit, that’s all.

As far I see D+ provides features meant to block screenshot grabbing (Direct Screen access monitor) and I guess there is no need to argue about methodology to wish that D+ will address Screenshoot #4 PoC like the other three Spyshelter screenshot PoCs.

Sound Recording and Webcam prevention were never introduced as D+ features though it still looks possible to Configure D+ to prevent both whereas sandbox is disabled (sound recording configuration rely on \RPC Control\AudioSrv preudo COM interface and will trigger such alert also when sandbox is enabled)

So, aren’t we all saying that testing is supposed to be done on the default configuration (sandbox enabled if speaking ov v4), and that therefore the sandbox should not be installed as default, and that the firewall/defense+ settings should be at higher degrees than the default ones today?

Under these conditions, CIS (factually using the v3 “expert” behavior) becomes very tight, and thus there shouldn’t be a default newbie installation and a default “expert” installation, but only a highly secured default installation, everybody being then free to overcome these settings.

The problem is that such settings are very unfriendly when starting to use the software or, said in another manner, that commercial considerations seem to be ranked higher than security considerations.

Yes that is what I am suggesting Brucine, but I think it is hopefully quite a simple fix / tweak to implement especially so that it can be understood by newbs. I am a bit tired now and not thinking too clearly but the basic method might be…

Any incoming exe not already on the system baseline and not recognised as friendly by CIS database should be given a default alert of suspicious file with 3 choices: 1) deny 2) sandbox 3) allow.

If deny, then it should be FULLY denied and not have access to ANYTHING, unlike today’s standard config that allows screenshots etc.

IF sandbox, then a warning that you execute it at your own risk although it is restricted something may still slip through (sandboxie users may laugh at this reduced effectiveness of comodo sandbox…just for now). But you have been warned at least as a newb.

If allow, then finger’s crossed as the exe is passed over to the system.

Microsoft Windows sound recorder qualified as PoCs under the same considerations for ages and yet nobody cryed wolf so far.
Any video chat application would have qualified as a PoC and yet it passed unnoticed until months ago somebody (probably videochat user) got a videochat PoC to to test V3 with.

Both sound grab and webcam monitoring were never implemented in D+ even if it apparently matter of a ruleset change.

Among the PoCs tested in these forums there are also mouse-move PoC (typical of Joke apps) AFAIK still not monitored as well.

On the other hand, Direct screen access monitor is indeed a D+ feature: first three screenshot tests are thwarted regardless if sandbox is enabled (without alerts) or disabled (by means of alerts) whereas the 4th Screenshot grabbing PoC would occur no matter the sandbox security level is set at.

I’m not sure why such tests should be used to generalize over some product “defaults” as if settings/options were not actually meant to be changed to match each user preferences whereas actually possible (and it won’t for the 4th screenshot PoC).

I cannot count anymore the times whereas somebody implicitly discouraged any new user to learn to use a HIPS when such feature (D+) was introduced in V3.

Well times change and V4 introduced sandboxing…

…and for one reason or another, a new controversy began to take place (again about new users or rather about defaults)

The thing is that the sandbox can be bypass.
On the other hand the default configuration is unsafe since the sandbox will never be 100% free of bugs (like any software in this world), no excuse for that.

Indeed yes. But what happens now? How does this kind of important issue get to be included on the agenda for assessment and decisions on what to do amongst Comodo desginers, devs, fixers, etc?

Whereas sandbox and D+ approaches might have different protective spans it might be relevant to confirm these differences whenever the narrow focus might be not enough to provide an unbiased picture.

Obviously it took no effort to leverage on the PoCs to claim “unsafety” whereas it apparently matters not how much safe an approach it is.

There is no need to claim that any software in the world will never be 100% free of bugs in an attempt to backup unsafety claims specifically targeting the sandbox whereas such statement was to be applied to “any software in the world”

Though such sensationalism might be enough to warrant generalized fear theres is still place in these forums to address these mystifications.

The sandbox is obviously not a panacea but fared as well as D+ whereas “defaults” are concerned.

No doubt improvements are possible but each member is entitled to acknowledge the PoC results and see whenever are relevant to their approach and needs.

Indeed Computer monitor access bypasses have been confirmed for both sandbox and D+ regardless of configuration changes.

Whereas a webcam lens cap (or a piece of paper) will be enough to thwart the videochat PoC it might be possible to guard against sound and webcam PoCs in case members are interested (IF they have a webcam and/or a mic)

Deny access should mean exactly that, no access to anything. It’s black and white for me, and that this should be for default setting, however achieved by comodo, and I do not think it is complex thing for comodo experts to implement and should not effect any other rules or configs.

Any devs reading this thread?