UPDATE: offending actions were performed via network communication between a sandboxed process and a non-sandboxed process. Obviously not a bypass of any kind then...

________________________________-
This occurs on both XP SP3 (32 bit) and Win 7 (x64). It occurs on 3.52 (win 7) and 3.46(xp).

I use the torrent tracker Vuze. I leave Vuze running for long periods of time, outside the Sandbox...

Now, lets say I download and recover a torrent file to My Documents. If I am in a sandboxed app and launch the file, or if I launch the torrent by using the Run Sandboxed feature, the torrent will start downloading in Vuze. The download is not within the sandbox, and can be written anywhere.

Not sure if this really qualifies as a bypass, but someone in another thread mentioned that ntvdm may be doing this when 16 bit applications write outside the sandbox.

If I were to do the same thing with windows media player, it would open up a new process and the new process would be sandboxed. Could this be occurring with processes that can only have a single instance? I can't launch Vuze more than once, and I know there are other programs like this. Not sure if that has anything to do with it, but it is the first thing that came to my mind.

If you have Window Access settings (in Sandbox Settings), they may have an effect on this behavior.

I just have acrobat and distiller are in there, but they were added by default (compatability template?)..

Could Vuze be watching for .torrent executions, and simply initiating the action on its own? I'm not really sure whats happening, or if it qualifies as a bypass.. but I'm definitely going from sandbox to outside the sandbox without any intervention from me.

Just installed Vuze in a Windows XP VM and I can reproduce the issue. It only works if Vuze is already running unsandboxed, as is your case. Seems like another one of those similar issues we've been seeing recently (eg. IDM). As mentioned in those threads, one "workaround" would be to force run Vuze sandboxed and/or never run it unsandboxed.

Hopefully this is a case like that of the download manager, where the program outside the sandbox is just monitoring events, and then performing actions based on this monitoring. In this case, there is no real breakout - all of the offending behavior occurs outside the sandbox and there is no communication taking place.

If there is communication between a sandboxed process and an unsandboxed process, such that the sandboxed process can use something like a system process (or even user mode) to write to the drive... then we have a problem.

From my observations, I suspect the unsandboxed Vuze (which is certainly a malware threat-gate and should never be run unsandboxed from a security purist's viewpoint) monitors for torrent files. When running the torrent file with the right click "Run Sandboxed" context menu option, I can see that another Vuze process tries to open sandboxed but then shuts down spontaneously and the torrent download is taken over by the unsandboxed Vuze (presumably because only one instance of the Vuze process can be present). I can't really see any "bypass" here. The way I see it, the key problem is that Vuze is run unsandboxed to start with.

It may be worth testing this issue with other applications like (censored), DefenseWall and GeSWall to see if similar behaviour is observed. Again, the issue would only be reproduced if Vuze was running outside of the "sandbox" to start with.

With regards to your concerns of a sandboxed process potentially starting or hijacking an unsandboxed process/service (and potentially initiate malicious activity), this may be possible? The concern would be most obvious with unsandboxed processes/services which are deemed safe and/or eg. required to run Windows smoothly. However, I think that such an event would only take place if malicious code was able to get on to the system and execute in the first place. I think the attack would need to be fairly targeted and rely on certain already present "holes" in the system. Examples of such "holes" would be running in full blown Administrator mode and/or not enabling Sandboxie's Drop Rights.

I've tried running Vuze inside the sandbox.. but the problem really comes in with file migration. I'd prefer to normally keep this on a reasonable setting (under 1 GB), but every now and then I get a torrent that is larger than this. While I like to put every internet facing app inside the sandbox, this one is a little impractical if I wish to keep a limit on file migration.



Well, I'd personally like confirmation that Vuze is actually trapping something, and there isn't something else going on here.

I have a lot of apps that are started outside the sandbox, and they don't necessarily have to be malicious to fall victim to malicious payloads. Macro viruses for the office platform is a good example. I actually don't run word / excel unsandboxed for this reason, but if I launched an .xls in the sandbox, I obviously would not ever want it to open in an unsandboxed windows of excel. That is sort of what happened here, and I just want to make sure that something else isn't going on here.

BTW, here is my access monitor code

If you always run Vuze sandboxed, there shouldn't be a problem because all your torrents will be created inside the sandbox. There's no size limit. The file migration setting only applies to files already existing on the real system, which must be copied into the sandbox before they can be modified. You should be able to leave it around 50 MB, not 1 GB.

I think you're having file migration problems because you already started torrents on the real system. To transition to a sandbox-only workflow, use Explore Contents to move all your partially downloaded torrents into the sandbox.

For more background info, see File Migration and Guest10's recent post.


I tested briefly with Sandboxie 3.53.05 on Windows XP SP3. From what I saw, Vuze always opens sandboxed first, and then the unsandboxed instance picks up the download and the sandboxed instance closes. This happens pretty instantaneously, as ssj100 described.

Steps:
1. Installed and ran Vuze 4.6.0.2 unsandboxed, using all default settings.
2. Downloaded a .torrent file to the Desktop using a sandboxed Firefox.
3. Double-clicked the torrent file from a sandboxed Explorer. Or, used Run Sandboxed from the real Desktop.
4. Result: Another instance of Azureus.exe ran sandboxed. Then:
- If internet access was enabled in the sandbox settings, the unsandboxed Vuze picked up the download and the sandboxed Vuze closed.
- If internet access was disabled in the sandbox settings, nothing happened in the unsandboxed Vuze and the sandboxed Vuze took a minute or two to open.

Btw, you can confirm that a sandboxed instance always runs by excluding Azureus.exe from start/run access - you should get SBIE1308 and a corresponding Application Error, and then nothing else happens.


UPDATE: Think I found the answer. Quote from the VuzeWiki:

So, when internet access is disabled, did the torrent still start in the unsandboxed version? I will test this myself.



So, this is information passed over the network port? That would obviously be outside the realm of sandboxie.. However, if the parameters would be passed by the actual process (from inside sandbox to out), I would think that might be a (small) security hole.

Nope. For me, nothing happened.

Ok, I just tested it, and now I understand what you are saying.. This program does require network access to pass the information, which is outside the realm of sandboxie... So we can close the case on this one..

..and you were right about the file migration. It looks like when I have a large file already in progress outside of the sandbox, it craps out when I open up Vuze in the sandbox. I never quite understood what was going on there, but now its clear to me. I can safely return Vuze to the sandbox now if I kill large unfinished torrents out of the queue.

PS - thanks to everyone for the testing and the help!

Just an update with other types of programs with an "unsandboxed" Vuze already running and trying to run another ("sandboxed") instance of Vuze via the right click context menu of a torrent file:
1. DefenseWall: successfully opens an "Untrusted" instance of Vuze and downloads the torrent in this "Untrusted" instance.
2. (censored): gives an error - unable to run another instance of Vuze. This appears to be purposeful.
3. GeSWall: same issue as Sandboxie - despite trying to run an isolated instance of Vuze, the torrent starts downloading in the unisolated instance.

So it appears here that DefenseWall is able to do what Sandboxie can't? Any ideas tzuk? If DefenseWall successfully runs another instance of Vuze, surely Sandboxie should be able to as well?

Well, one defense I think would be to block sandboxed programs from communicating with the localhost/127.0.0.1 and any local address or port not opened by a sandboxed program.

Not sure what defensewall is doing though...

I think this is a specific problem between Vuze and Sandboxie (and perhaps GeSWall also) - there should be a way to open another instance of Vuze sandboxed. Not being able to do this results in the issue above. DefenseWall shows that it's possible to open more than one instance of Vuze.

With an unsandboxed instance of Vuze open, I am unable to run another instance of Vuze sandboxed. As mentioned at least twice in this thread, Sandboxie tries to run it sandboxed but then spontaneously "gives up" and the unsandboxed instance of Vuze is called instead. This really should be looked at, in my opinion (and the current thread title should be changed).

I would prefer a result like this too... but it appears that all the communication is being done over network protocols. As I'm sure you know, Sandboxie doesn't really control network traffic (other than blocking a few ports).

Vuze is essentially starting a new instance of itself, but it immediately detects that another instance is using the control port. Since it can't seize the control port, it passes along information to this network port telling it what torrent file to open. The unsandboxed Vuze gets this information via the control port and starts the torrent.

I would assume that the only way to really prevent this would be through some network control magic. I would think you'd have to blind the sandboxed app from any open ports on the local system, and disallow communication to any network ports used by a service outside the sandbox. Its sort of like if you had an SSH port open, and a sandboxed utility used SSH to make changes to your system. How do you stop that without initiating controls at the network level?

Maybe there is another and more clever option, but I can't picture it. The only other things I can think of would be Vuze specific, which wouldn't be all that helpful in the grand scheme of things..