CIS v 4 Sandbox bugs n design flaws

Tested a rouge and some applications in Comodo sandbox in VBox Win 7 32 bit. Here are my results:

1- Auto sandboxing doesn,t work. It says that application is sandboxed but it,s in fact never sandboxed.

2- Sandboxing via right click menu, Run in comdo sandbox, works and system is intact.

3- There is no way in CIS GUI to see what processes, files and reg enteries are isolated.

4- Once an application is sandboxed, there are no more defence plus alerts for it( it must be optional IMO, I mean user must be able to choose to have or have not the alerts).

5- Same seems true of FW alerts. FW alerts must be there as Sandbox itslelf has no inbound/ outbound control at all.

This is what we were trying to explain yesterday here:
and here:

Thanks for take some screenshots, I didnt want to lose more my time after report many bugs in the last RC and see all of them and all the others in the final version.

It,s really disappointing that sandbox has major flaws and lacks many essential features. I will consider it a beta, not even RC. I can,t understand why they rushed for an early release.

If ever they want a good sandbox, they need to keep the example of Sandboxie in front of them.

[b]I got D+ and firewall alerts for sandboxed applications. I removed the outgoing rule from network security policy and set D+ to Paranoid mode. I also removed the Trusted Software Vendors option, and got tons of alerts.

Thanks for that Aigle, really appreciate it.

In the threat model, I really don’t see a CIS user wanting to install an AV, never mind a rogue AV! The %age of people who were able to find CIS (as you know it doesn’t come with a PC installed etc), which means they know what they are doing or someone else did the work for them, then deciding to search for another AV while they are using CIS is negligible imo.

Nevertheless we’ll look into it and see what we can do.

thank you again


What does this mean? I havent understood anything from the attached screenshots…So please tell us what you expected to see and what you havent seen. Screenshots give no information.

Hi Egemen

Feel free to see my thread here…


Hmmm… I think you failed to understand my post.

Problem is not one rouge or any malware. Problem is that Comodo Sandbox is NOT WORKING. It says that it has auto-sandboxed an xyz application but infact the application is NEVER auto-sandboxed.

Now do you think it,s a trivial issue or major one?


Hi, I think I made it a bit confusing. Let me repeat.

Auto-sandboxing feature is not working. If you run an unknown application, say xyz.exe, CIS reports that it has sandboxed xyz.exe but infact xyz.exe is NEVER isolated. So auto-isolation is not working. All the files created by xyz.exe will be out of Sandbox folder. Nothing is created inside Sandbox folder.

As far as the pictures are concerned they are in fact showing the sandboxing working when an application is run inside sandbox via right click menu. in this case all files created by sandboxed application are inside Sandbox folder. I will remove them now to avoid confusion.

@aigle: Sorry, virtualization is not intended for auto sandboxed processes.

I’m not sure, why this is by design. But probably the decision was made because of tons of problems due to mass virtualizing applications.

I’m not happy with this concept either. Maybe some more explanations about the intended behavior would help to reduce the frustration and confusion.

Hmmm… so may be we need to understand comodo sandbox in detail.

Just yesterday I ran xyplorer and xyplorer.exe was sandboxed automatically. Through xyplorer, I tried to delete many executables with path C:\Pasted Software* and was able to delete them. Is that expected?


I don’t want to start up the programm in sandbox, but i don’t want this programm in “my safe file”. What i can do?

As I understand Egemen, this depends on your configuration.

  • If you need Administrator privileges to access "C:\Pasted Software" or to modify anything in there, this should be blocked by Windows with an error, that you haven’t sufficient access rights.
  • If the executables are in the protected files list (i.e. as “*.exe” or “C:\Pasted Software*”) it shouldn’t be possible to modify/delete the files, since Defense+ should silently block this.

But I can only interpret Egemen’s post. For a competent answer, you’ll have to wait for anyone from the development team.

Yep Automatic sandboxing is, by design, does not enable vritualization right now due to compatibility concerns. Instead, we have modified Defense+ so that it limits the file system/registry modifications. Ie. it blocks all protected registry access and blocks all protected file modification attemtps.

A sandboxed application can drop files(but can not modify existing files i.e. infect them) to the locations it has access rights.

Thanks. I hope it will take some time for us to understand this sandbox and then we will see how strong and clever it is.