Does Sandboxie have self-protection?

If hacker detects virtual sandbox (of Sandboxie) and wants to shut-down/terminate Sandboxie and any/every or all of its processes, would be he/she able to do it?
I never asked this before, I also never tried to shutdown it in Task Manager or any of its other processes in C/program files/ or in the registry or anywhere else...
Does anyone knows this?
Should I have something with Sandboxie, so every and all of Sandboxie processes remain fully protected from termination/shutdown?
Thanks to all.

 

I'm fairly new to all things Sandboxie, but I'm sure it does (a quick search of its forum didn't say much on the subject.). I'm not all that certain it's a really big issue though. If it's not allowed to run within Sandboxie, the malware will just sit there. Also, provided you have it enabled, Drop Rights will limit its abilities. You're probably better off waiting for more knowledgeable people to chime in, but that's my take on it.

 

I'm not sure, but I think that terminating Sandboxie would be tantamount to deleting the sandbox which would defeat the malware itself...

 

The way I see it, if a malware wanted to terminate Sandboxie it would first have to get out of the sandbox, which it cannot do. In fact some viruses kill themselves when noticing they are inside a sandbox.

Sandboxie main function (nothing goes out to access critical areas of the machine) works as well as self-protection.

 

I think if the malware was pre exsisting on a machine already then probably could kill off just about anything but as far as malware contained inside of sandbxie,no I doubt it.Also with the restrictions of SBIE you could choke the life out of malware in a heartbeat.

 

Sure why not? All that malware has to do is crash the sandbox.

 

Spot on!

 

Anything outside the sandbox , hacker/malware could easily terminate sandboxie. Anything inside the box, cannot make changes outside.
There is a way to password protect the configuration , and to allow only admin users to do the same , but that's not what your asking .

 

What about simulated mouse clicks and task manager kill off, none of the Sandboxie's files are protected against termination, I guess the answer lies in fact that everything from internet surfing cannot terminate Sandboxie because all malwares and and all internet are sandboxed, but if you already have malware whose speciality is to terminate anti-malware products, than SBI would terminated, right or wrong?

 

This is not strictly true in regard to malware not able to break out of a sandbox.
Over at the windows7 forum there is a thread about a software developer who has created a POC which can break out of a sandbox.so it seems it is possible.

 

When he creates a pogram instead of a POC, I'll belive it.

 

If you look at a default sandbox, there are no settings which restrict what may run, so an exploit would be able to attempt it.

However, the first hurdle to clear would be how can a child process terminate its parent and not also terminate itself? The exploit would have to first find a way to escape the sandbox and run under a different parent or be the parent process itself. If something can do that, then it would not need to disable the sandbox, as it is already clear of it.

If the process cannot escape the parent process of the sandbox, then it only terminates itself in the process. It could be an annoyance, but doesn't seem productive for the exploit really.

There is no use discussing a process that is running on the host system. Sandboxie really doesn't concern itself with the host systems processes, nor should it. It is designed to contain a process only.

Sul.

 

Can you provide a link ? I've heard these claims before, one on this forum. If I'm not mistaken, he was just lying, can't remember the reason

 

@Sully,

Will there be any setting in SBIE that will protect itself, say, If there was a malware that got into the system via another way, say, a USB perhaps and that particular malware wanted to terminate the SBIE program itself or prevent SBIE to run so the user will have to use the browser without SBIE. Just asking...

 

The config areas "Restrictions" and "Resource Access" hold some settings that could let certain actions happen with the host. I have not researched these at all so cannot say what could happen, only that they allow some lower level acivities which might be used in an exploit. The default settings don't allow such things, but do allow anything to attempt to execute within the sandbox. From that standpoint, there is nothing I see which should allow a sandboxed process to interact with the host in a way that would allow the sandboxie control to be tampered with.

Enabling some of those more powerful features might though.

In regards to a process running on the host, IMO all bets are off. Simulating keystrokes from an elevated prompt could do it. Simulating keystrokes/mouse clicks is even enough. If the host has a process running, and there are enough privelages, then SBIE offers nothing that I have seen to counter this. I could write a batch file that would disable it, then all I need to do is compile that as an executable and trick you into running it, elevated of course.

I don't believe protecting itself from the host is a job SBIE should even be performing personally. If the host is running something that can compromise sandboxie, then something somewhere went wrong. Not only that, but why would I even want a sandboxed environment when the host is compromised? It takes all my security provided by sandboxie and throws it out the window.

If one assumes that a process ran on the host that disabled sandboxie, it would likely be safe to assume that the user would be observant enough to detect this, either by seeing the sbie_ctrl icon missing in the tray or the lack of the border or [#] indicators of the processes that should be sandboxed.

Should an exploit exist that runs in the host and disables sandboxie, it better be able to make my normally sandboxed processes "appear" to be sandboxed, else it will not live long enough to do any damage on my system anyway.

Sul.

 

Very nice explanation there Sully.

 

This is the way I understand this. If SBIE processes "could" be killed, whats inside the sandbox remains captured by the driver. So, even if SBIE processes are killed or they are shut down by you, me or malware, nothing escapes the sandbox.

Bo

 

I'm not sure that this is always the case. Killing the parent process does not necessarily kill the child process. You can launch process explorer using windows explorer, then terminate windows explorer with process explorer, and process explorer keeps running. That said, killing the sandboxie processes doesn't automatically equate to an escape. I did a quick test using scanner, a little utility that displays drive and folder usage as pie charts and integrates with windows explorer. I launched scanner sandboxed, then killed SbieCtrl.exe and Sbiesvc.exe using SSM. Even with both the control and service killed, files I deleted with Scanner were not deleted in the real folders. This was not a thorough test by any means, but it does show that it takes more than just killing the sandboxie process and/or service to escape the sandbox. It would also be much more difficult to kill sandboxie from within. All of this also assumes that Sandboxie is standing alone. If Sandboxie is defended by another security app, like a classic HIPS that's configured to protect Sandboxie's processes from termination, suspending, messaging, etc, such an attack would be all but impossible.

 

You are terminating processes from the host though. That is not a proper test, as a simple batch file can do that, and SBIE isn't designed to control the host, only the virtualized sandbox.

By terminating these you don't stop the driver itself from maintaining control. You can note that the processes running in the sandbox have no parent process (it doesn't exist) but since the driver is in control, it works. This also doesn't change the fact that the sandboxed processes are not going to be modified to either be a parent process themselves or become children of some other process.

In fact, the only test that would have any merit at all (the way SBIE works now anyway) would be for a sandboxed process to terminate the sandbox processes. I get access denied when I try that. Of course some really intense code might be able to do this. But to be conclusive, such tests as those you ran must be performed within the sandbox.

Not that it wasn't a cool thing to try out. I did it too, just to see. Always learn more when you experiment

Sul.

EDIT: I would be very curious to see though, if the sandbox were terminated from within, if the sandboxed processes were also terminated. They aren't, as you state, when you terminate it from the host.

 

Not that I know of. As several have stated though, it's kind of a moot point, as malware terminating the sandbox would be shooting itself in the foot.

I enable protection from termination in my Comodo D+ though. In the "Protection Settings" tab, activate the one for "Process Termination" for the Sbie services. I do this for several internet facing apps, including Firefox as well.

Good ol' D+. What a great hardening tool.

 

I'm not really sure, I still think SBIE should have self-protection just because if open file outside the sandbox. for example I always use Kaspersky's tdsskiller. I always check my computer with it. One day, I also was checking rootkits with tdsskiller, until it said that that an process inside sandboxie was rootkit (of course this was false positive, after I later contacted Kaspersky via e-mail and solved the problem), I deleted this so-called rootkit and Sandboxie was terminated immediately, so yes, I really think SBIe should have self-protection (what would have happen if this was a real malware?), based on this experience, because I did not expect this to happen.
I was very disappointed about this.

I'm not that experienced, but from this small experience I'm very anxious when it comes should SBIe have self-protection or not, it definitely should.
Of course I could be wrong, because I really don't want anyone think I'm the smartest, because I'm not the smartest, I'm far from being the smartest when it comes to computer security, I'm more like scared of this sandboxie termination happening, that's all.

 

Personally I don't think software like SBIE should even bother with the host OS. If you have something running on the host that can effect the sandbox negatively, you are going about it the wrong way to begin with.

If there were to be any self protection, it should be directed at the virtual environment. Just my opinion.

Sul.

 

Nothing. Sandboxies role is to keep whats running inside the sandbox in the sandbox unless you recover it and thats what would happen if SBIE is terminated. Once or twice during the time that I have used SBIE, I had SBIE terminated for X reason and thats what I have found.

Check it out yourself. Run something sandboxed, right click on the SBIE icon and click Exit. After you ll restart SBIE, you ll find contents in the sandbox that can be easily deleted.

Bo

 

Nothing will happen especially if you have Drop My Rights enabled. SBIE will contain it inside the sandbox unless you recover it or set Delete Invocation to "Automatically delete contents of the sandbox".

 

I am curious, why do you think the DropRights feature would have an effect on sandbox termination from an already sandboxed process?

Sul.