Sandboxie technical tests and other technical topics discussion thread

I have been a Sandboxie user for six years, to this day, I still have not seen anyone reporting a real world browsing infection at the SBIE forum. Obviously that means that Sandboxie works. CWS, Sandboxie can not be any better than what it is.

You know, I don't go along the layered approach. In fact, I believe I am safer using Sandboxie on its own than using an army of programs to take care of this and take care of that. The only other program that helps me, security wise, is NoScript. To be safe, I totally depend on Sandboxie and what I have learned from coming to sites like Wilders and the Sandboxie forum. But to this day, I am a still a dummy user. And this dummy user has not seen any malware come around knocking on his computers doors ever since the day that I installed Sandboxie for the first time. For me, its like malware doesn't exist. I believe, the way I personally use Sandboxie is a good test for SBIE itself. If SBIE was a so so program, I would have gotten infected quite a few times during this past 6 years. But no, for me malware died the day I became a Sandboxie user.

Later CWS

Bo

 

AKAIK, the Master (or Broker) runs at medium IL, but I'm on Linux so long now that I'm not sure. Check this out:

-http://www.chromium.org/developers/design-documents/sandbox#TOC-Sandbox-windows-architecture

This is interesting too:

-https://media.blackhat.com/eu-13/briefings/Wojtczuk/bh-eu-13-thes-sandbox-wojtczuk-slides.pdf

EDIT

it looks like the gpu process of chrome.exe runs at low il while the main chrome.exe broker runs at medium il, at least on my Windows 7x64 setup, and that's if I'm interpreting Process Explorer information correctly.

 

@cws
You firstly have to understand for what I'm (or other member here) saying those, and in what context.
Are you a person who can be targeted by three letter agancy or national army or any other orgnization who don't care about spending lots of money & time to infect you?
If not, you need not to care about SBIE exploit.

I never said you shouldn't combine SBIE with Chrome.
Also I'm 100% sure about untrusted IL as I confirmed it via System Explorer.
Broker runs in midium IL, but I'm not sure what you mean by saying key difference, difference btwn what and what?

 

No. I never said it this way.
Chrome exploit protection protects chrome processes. (And this protection consists of more than inegrity levels)
Sandboxies own exploit protection protects sandboxie itself. Sandboxie adds nothing fundamental in terms of exploit protection to chrome, but some other nice benefits (virtualisation, restriction...etc.)

So it's not an A vs B, cause it are different types of programs.

 

Actually, I'm much more concerned about net banking/shopping with Sandboxie.

 

I understand now, but I still think it's good to have another layer of protection over Chrome, and this is why I have 100% decided to use Google Chrome under Sandboxie4's supervision/protection, just in case.

 

Quite ok, as i mentioned earlier Nothing speaks against and sandboxie brings some extra benefits (security and comfort wise)
I would do the same (but I'm not a chrome user)

Regarding your shopping concerns...no need for them. Alway start those applications with an emptied browser sandbox and it should be very very secure.

 

Like I said before, maybe this true type vulnerability was unknown at that time, but the fact is you could have before that block all dlls from start/run in the first place, so SBIE would eventually block it, the only problem is that if Duqu start to target Sandboxie4 via API, than the game is over, since we're talking about kernel-level threats in the first place.

 

I'm sure Curt was aware of this and tried to minimize the damage from exploits which do not need start/run restrictions in the first place-and this is why he said nothing has been exploited, because he found the way to block even those exploits which do not need start/run restrictions in the first place.

True but here is the thing if you have for example buffer overflow exploits Sandboxie's restrictions can and will block that (someone has tested this on Sandboxie forums a year or 2 ago), Now Chrome cannot really block something like this in the first place, so yes, it's good to have Sandboxie over Chrome for Chrome's protection.

I've been reading about this increased attack vector, but this is merely a theory, not a proven fact, also SBIE protectiong Chrome could decrease attack vector, as well.

True, but like I said, if Sandboxie can block everything that does not need to communicate with Chrome (with restrictions and etc.), than obviously it gives more benefits/protection to Google Chrome, than just run/surf/browse the net with unsandboxed Google Chrome.

 

I'll. answer to you what I answered to SLE:
True but here is the thing if you have for example buffer overflow exploits Sandboxie's restrictions can and will block that (someone has tested this on Sandboxie forums a year or 2 ago), Now Chrome cannot really block something like this in the first place, so yes, it's good to have Sandboxie over Chrome for Chrome's protection.
If Sandboxie can block everything that does not need to communicate with Chrome (with restrictions and etc.), than obviously it gives more benefits, more security, more protection, more privacy to Google Chrome, than just run/surf/browse the net with unsandboxed Google Chrome, because it would simply vastly minimize, as much as possible, Google Chrome's communication with the net which also means that it directly minimizes potential attacks that are trying to bypass/exploit Google Chrome in the first place!

 

Sandboxie does not have anti-exploit functionality that programs such as MBAE and EMET use.

 

Hey you dummy, keep your wisdom coming to us who are even more dumb, please!
Acadia

 

But it does protect against exploits with the thing called containment, which means the rest of of the system/the real system is fully protected, Tzuk and Curt obviously know what they are talking about.

 

Exactly, each and both SBIE (yes, SBIE woudl protect everything that is inside sandbox, plus if you include internet access restrictions and start/run restrictions, than duqu is defeated in the first place) and AppGuard and DefenseWall, also, would protect against Duqu since it was infecting MS Office documents.

 

So are you saying browser is just as safe when installed inside a created sandbox which allows all programs
Internet Access and all programs Start/Run Access as installing browser outside sandbox with
only the browser allowed Internet Access & Start/Run Access in Sandboxie restrictions?

Something else to consider. If you install a program inside of a sandbox like a browser and somehow the sandbox gets infected then you would either have to disinfect it or delete the contents of the sandbox.
If you choose to disinfect you would have to make sure you cleaned up all the infection and hopefully everything works as before. (Antivirus apps have been known to sometimes mess things up)

If you choose to delete the contents of the sandbox then you have removed infection, but lost your browser and
have to reinstall the program all over again.

Of course one could backup the sandbox right away before infection takes place.

 

If it's exploited, I don't see how containment can't be bypassed.

Theories aside, I have yet to see the security benefits out of sandboxing non-malicious software in the real world. That is especially true for something already secured to the extent of Chrome, provided that the following criterias are met:
1. Your OS and the said program is up-to-date.
2. You're not a click-happy user.
3. You're not looking for more control or privacy.

Of course there are rare exceptions, but I have yet to experience them, much like winning the lottery. I'll admit what Bo has done is more secure than what I'm doing, but the extra convenience is more than worth the extremely tiny risk IMO.

 

If Sandboxie was the one that got exploited then there would be a problem. But that is not happening in the real world (the one that really, really counts). Sandboxed programs might happen to get exploited but in the SBIE world that dont mean nothing, the infection is isolated from the system, files and registry and gone when the sandbox gets deleted. In my opinion, it cant be any better.

And in my eyes, sandboxing files and programs is so easily done, all done automatically with so little thinking being required, that makes using Sandboxie very convenient. I cant understand why you think sandboxing files and programs is inconvenient. I mean, if I want to run a file or open a program, I just click on it and it runs sandboxed, usually in its own sandbox, that is tailored according to the program. Doing that is not inconvenient. There is no delay or anything.

The reason to sandbox non malicious programs is the same reason why people sandbox their browser. Just like the browser, your PDF reader, video players, Office programs, etc, can be exploited and infected. By sandboxing all programs and not trusting any, I keep the system intact.

A comparison for you, J L. If I send you a Word file in an email, you ll scan it with your antivirus and upload it to Virus total. Right? Thats pretty much what you would do. But if you send me one, all I do is click on it and if I keep that file in my computer, it will run sandboxed until the day it gets deleted. All done automatically, no headache and it works .

Bo

 

Actually does protect against memory exploits, in a case you don't know Curt answered the question about the file-less/memory based Angler exploit kit, Curt has answered the following:
Angler has not crossed our radar screen here. Sandboxie protects against these things because all sandboxed processes run at untrusted integrity under anonymous user login credentials. If they break out of Silverlight (or whatever), they will still be fully contained inside Sandboxie.

 

If you read it carefully you see the answer is exactly the same thing like others and I said several times in this thread.
1. Sandboxie protects against everything that comes with or better after exploits (payloads etc.) because exploits are only a first step in an attack and then try "to do more." All of those changes are contained, system can not be infected. Secure.
2. Sandboxie does not much to stop the exploitation of sandboxed processes in the first place (first stage). Here most restrictions won't help, cause it's often the same process. F.e. firefox is allowed to run, but firefox.exe is exploited via memory/plugin etc. But in Sandbox logic that's not dramatic because all is protected at the next stages. BUT: Here is the difference. The first stage is protected by applications own mechanismns (f.e. Chrome) or partly by specialized tools (f.e. Emet) and not much by sandboxie.
3. Conclusion: Exploits of sandboxed processes should not be able to break out and infect system, damage can happen only inside the sandbox and is gone after deletion of sandboxed contents.

That how it works and how it should work.
I hope it gets clear and when looking at the stage 1 vs. 2. vs. 3 ...points, for me it clears most of your questions and difficulties.

 

An exploit would have to do both the target application and then open it up further from within Sandboxie (presumably harmless), or then go on to attack Sandboxie itself.

Personally, and I do develop software, I find it very difficult when people talk about up-to-date and being a savvy user. The reality is that most programs are dependent on legacy code and/or utility libraries. Both of which may/will contain many potential zero-days which may have been there for years. I don't find the configuration and use of Sandboxie a big deal at all - try AppArmor in Linux if you want complex!

Whereas people may not be aware they want more control or privacy, I suspect that more exposure to exfiltration and ransomware (which are not that rare, they are real-world) will come to change their minds. It's absurd that the OS natively allows unfettered access to all your disks to things like browsers for example, and that's one of the key features I use Sandboxie to contain.

 

@bo elam: I really do like your approach, but it isn't quite feasible with the amount of changes I make to my system every day. Different strokes for different folks.

@deBoetie: Yet it works in real life. I have yet to see any exploits working just from browsing the Internet, opening non-executable files, etc. I do use anti-exploit software though (being more convenient than SBIE imo), but never seen them in action. Sorry, you won't see any adware on my system, much less ransomware.

 

Please help me try to understand, when Chrome Security is based on OS-mechanisms and SBIE is based on OS-mechanism (lower level objects can't touch higher level objects) why would SBIE be stronger as Chrome when it concerns breaking out of the this OS-based sandbox?

The only thing I can imagine is that the additional SBIE restrictions and side-by-side (hook based) protections make it more complex to exploit a bug in a predictable manner. On the other hand most of the buffer overflows based exploits bypass those extra (API/hook user mode level) protections anyway. So this "SBIE cannot really block . . " is a bold claim IMO.