How to clean sandbox after exiting sandboxed app?

I sandboxed IE7. I then went to a site (SysInternals) and downloaded a file. Because no indication is shown that an app is sandboxed (like a colored border or something in the titlebar), I forgot the web brower was sandboxed. After download a file (Process Explorer) from the site, I couldn’t find it where I said to save it. Then I remembered that I had sandboxed the web browser. I noticed that if I did the download again that the file was already listed (in the sandbox) from the prior download. That is, when I had exited the web browser, the file that had been virtualized in the sandbox was still listed in the next we browsing session. Apparently the sandbox does not get cleaned out when the sandboxed application is exited. Very sloppy.

The path where the downloaded files went into was:

C:\Sandbox<appfilename>

There is no differentiation between multiple instances of that application. That is, if I start N copies of the same app, they all share the same “virtual” (redirection) folder. Not only is the virtual store not actually virtual (it’s on the same disk and in the same partition as the real OS without any real separation), and not only do multiple instances of the sandboxed application share the same sandboxing folder under C:\Sandbox (which means there is no isolation between the sandboxed apps), but there is also no cleanup when that sandbox is no longer applicable (to clean the virtual folders which are actually accesible by the user and still pose a threat).

In Sandboxie, you could have multiple instances of the same app share the same sandbox. You could even have multiple different apps share a common sandbox. Or you could have each instance of an app in its own sandbox to isolation any collusion between them regarding malware behavior. But however your shared or not, the sandbox could be cleaned out so no remnants lingered into the next app that reused the same sandbox. As it is now, the virtual store for the sandbox isn’t hidden to user processes because a kernel-level file driver isn’t hiding the virtualized paths. Any user downloading a file in a sandboxed application can still access and execute that downloaded file just by knowing about C:\Sandbox (rather easy to discover) or by doing a file search on it.

The only good protection that sandboxing gives might actually be a separate function of the Defense+ module, which is restricting privileges on the untrusted process by assigning an LUA token to it and its child processes. I could get that with SysInternals psexec or with DropMyRights except those don’t handle child processes that are started separately of the shortcut used to run psexec or dropmyrights; for example, clicking on a URL link in an e-mail starts a child process to load the web browser that wouldn’t have its privileges restricted under a LUA token. Online Armor has its Run Safer feature that can enforce reduced privileges on a process regardless of how it got started. I figured with Comodo’s sandboxing that an additional layer of protection beyond reducing privileges would be available but it doesn’t look like very good sandboxing so it isn’t a strong argument against other security product that don’t have sandboxing to qualify Comodo’s product over others.

Guess I was expecting more than just redirects to alternate folders for sandboxing or, at least, decent cleanup of the sandbox with the sandboxed app was exited. I’m really not interested in malware that supposedly got sandboxed (it download but couldn’t execute due to reduced privileges) but lingers around to have my anti-virus program throw up alerts on what should have been discarded after the sandboxed app was exited.

The application of sandbox in CIS is not the full sandbox but only an extra way of protecting against threats. You may want to check the post at the very beginning of this forum: https://forums.comodo.com/defense-sandbox-help-cis/how-the-comodo-sandbox-works-t50176.0.html

Cheers

I had read that other article (which definitely needs updating to reflect the RELEASED version of the product) but it doesn’t clarify the limitation of Comodo’s “sandbox”. That Comodo calls it a sandbox is misleading. There is only a partial implementation of sandboxing but that’s like saying a body frame makes a car. I have also trialed GeSWall which is a access control policy enforcement security product along with some folder redirection but they don’t go marketing their product to say it does sandboxing. In fact, when you speak to them about it or read their web site, they like to skirt the sandbox word and prefer to call it a protected environment because “sandbox” would be misleading as to what type of protection is afforded to the user. Only a portion of the virtualizing is performed but they primarily rely on policy enforcement on the isolated app while also monitoring the downloaded files so they also run isolated inside the protected environment by default (with a prompt to let you choose protected or unprotected). However, because GeSWall is not a full sandboxing product where its protected environment would be wholly virtualized (e.g., Sandboxie), it is still possible to get malware files on your host and they may even run, except they should run inside the protected environment (as may also happen with Comodo’s “sandbox”). A web browser running virtualized in sandboxes or isolation environments can still end up with malware inside that environment so, yes, your non-virtualized host might be safe from the pest but not the isolated app. If the malware were a keylogger, it would still be logging all your keystrokes inside the isolation environment and sending them out to be recorded. So that the keylogger was isolated does NOT protect you from having your site logins, credit card numbers, and other sensitive information captured and sent out. The malware supposedly just can’t get at the files in your real host to capture that data. That’s why I’d want the sandbox or isolated environment cleaned up each time the protected app was exited. At least the pest won’t be around the next time to keep on doing its nasty stuff inside the sandbox.

GeSWall doesn’t pretend to be a sandboxing security product. Sandboxing incurs its own nuisances on users that GeSWall (and probably Comodo) are trying to avoid. So they sit somewhere between a sandbox and a policy enforcer (GeSWall enforces it own acess control policies while it appears Comodo uses the OS to run the isolated app under a LUA token to reduce it privileges). Comodo is misusing the term “sandbox” because users have heard of the term. From what I understand of the various protection environments available, going from most secure to least, I would rank them as follows:

  • separate physical host
  • separate physical host
  • multibooted separate instance of OS
  • virtual machine (VMware, VirtualPC, VirtualBox)
  • sandbox (Sandboxie)
  • isolation & access contol policy enforcement (GeSWall)
  • isolation & privilege reduction (Comodo “sandbox”)
  • UAC (privilege reduction, “low” insecure zone)
  • non-mainstream apps (e.g., Chrome or Firefox instead of IE, PDFxchange instead of Adobe Reader)
  • regular host (with the addition of anti-virus/malware programs)
  • unprotected host (plain-vanilla install)

I was hoping by the use of the term “sandbox” that Comodo was doing more than just some folder redirection. There does seems to be some isolation of the “sandboxed” app by Comodo. However, since GeSWall isn’t willing to abuse the sandbox term, Comodo shouldn’t either. In fact, Comodo’s “sandbox” seems more akin to Vista/7’s UAC than of a sandbox. Rather than say the app is sandboxed, Comodo should say it is isolated. Isolated isn’t as secure as sandboxed, but sandboxed is more nuisancesome to users than isolated.

I have realized a side benefit of using Comodo’s pseudo-sandbox: you can turn off file virtualization of the app you add to “Programs in the Sandbox” and just have the app run under reduced privileges. This is like using SysInternals psexec or DropMyRights to run the app under a LUA token (however, only for the app specified to those programs) but hopefully it will also act like Online Armor’s RunSafer option that will catch the process even when started as a child process. That way, when you click on a URL link in an email, for example, the instance of the web browser that gets started would run under reduced privileges. So you can remove some of the nuisance of isolating the app (but which also lowers security) if all you want is to run the app under a LUA (limited user account) token to reduce its privileges. One of the reasons why I kept going back to Online Armor was because of its Run Safer feature that would ensure a process, no matter who started it, would run under reduced privileges. Maybe Comodo can do the same. Sandboxing has always incured a large enough nuisance level that I would instead choose to go with a virtual machine. I get only a little more nuisance with a VM than with a sandbox but better isolation with a VM than a sandbox. I found GeSWall still a bit too nuisancesome (they would only need to make one change regarding window messages and which apps allowed them for me to use it). Online Armor’s Run Safer let me increase security via reduce privileges with very little impact on the use of the app, and disabling their Program Guard was easy via their tray icon (so, for example, I could use the Windows Update site to install updates). With a web browser added to “Programs in the Sandbox” but with file virtualizing disabled for that app, I might get the same in Comodo as the Run Safer option in Online Armor (I have to yet test if Comodo catches the app started as a child process to enforce a LUA on those children, too).

The isolation environment afforded by Comodo’s “sandbox” needs to be cleaned up when the last application that is using that isolation environment has unloaded. Users don’t want malware left on their host. Even if that malware did get confined to execute just within the isolation enviornment, it can still cause harm to the user, like a keylogger capturing and sending site logins, credit card info, bank info, etc. If the isolation environment got cleaned, the pest disappears when you exit all the isolated apps (since there is only one isolation environment available with Comodo), or it should be made a user-configurable option. Some users would prefer to clean out that single isolation environment when all isolated apps were unloaded (i.e., no isolated apps were running anymore). Some users might want to keep it dirty so they can reuse the cached files in the TIF within that isolated environment for the web browser they repeatedly run isolated. Right now, users have to go do what cleanup they can (by having the isolated app cleanup its temp folders before you exit it and then delete that app’s subfolder under C:\Sandbox).