Application Sandboxes: A pen-tester’s perspective

Yes it does matter in real world scenarios, because the point is to prevent malware infections
And tightly configured SBIE should be tested, not SBIE with default settings.

None argues this, however in SBIE you have betters means of control, on what can start/run and what can have internet access-by default Chrome beats SBIE, but tightly configured SBIE beats down Chrome (even if it's tightly configured, since it does not have a wide range of control on SBIE's level)-when it comes to security.

When it comes to security nothing is redundant, but you have to look up for simple solutions not complex ones and SBIE is pretty much all-in-one package since it has many configuration options-that's what makes it better than Chrome.
The only thing you need with SBIE is good quality firewall. I have Edimax router with SPI+Firewall both enabled, tweaked on maximum level, plus Windows XP firewall block everything incoming/outgoing, tweaked on maximum level.
The only other thing I use is removable drives write-protection with small NoAutorun software application as well, just in case.

 

It wouldn't matter for a user like me who doesn't just execute anything I see or have a infected system that needs to be isolated. Yet some people treat my proven track record (and many others without SBIE) as reckless.
Good luck with that, any recommended settings that all Sandboxie users would agree on?

Exactly, that's the only real world threat for a user with the right mindset. And another repeat: https://www.wilderssecurity.com/showthread.php?t=339348

Here's simple, Windows Firewall with outbound control, group policies like Applocker or SRP, and Chrome hardened to your liking. One less software to factor. Whether that's a good thing is to be seen, but it's far from as badly lacking as many of you think.

 

J_L, stating that using Sandboxie together with Chrome is simply "sandboxing a sandbox", and therefore, redundant; and that every exploit that is able to bypass Chrome is also able to bypass Sandboxie, is pretty much ignoring all the other layers that Sandboxie implements that are not present in Chrome and that are able to prevent infections (run/internet access restrictions, prevent programs from accessing personal/sensitive data, clear all data between sessions, forced folders and programs, etc.).

The statement that Sandboxie and Chrome are redundant is false, and may lead people to think that they benefit the exact same protection under Chrome either they're using a tightly configured Sandboxie or not.

I understand if you say that the same effect of Sandboxie can be achieved by combining Chrome's sandbox with "unique layers effective at mitigating Chrome's weaknesses" like "HIPS, default deny policies, incognito mode, etc.".
But that's much different than saying that Sandboxie and Chrome are redundant.

Probably the most accurate is to say that they are *partially* redundant, what opens the possibility of using other software / restrictions to complement Chrome sandbox, instead of using Sandboxie.

 

"Real world security" is by itself subjective. Sandboxie is not needed for MY real world security. Chrome's built in sandbox is also redundant. The same goes for HIPS, AV, SRP, LUA and others. At the end all I need is router with firewall, updated system and applications and maybe backup of my system. For me everything else can be considered as redundant.

But I guess we all like to have something more than we NEED for our real world security.

 

Very well said.

 

@AlexC: I'm fine with that, although the core feature not easily replicable by Windows itself is virtualization and that is now implemented through the same process.

Unfortunately too many people are defensive at even considering security without Sandboxie, especially at someone who spreads that fact.

@tomazyk: Of course, that's the whole point. There are viable alternatives.

 

And you can do all that with SBIE without so many solutions, SBIE is all in one solution, plus with SBIE you can block access to whatever you want from your entire operational system to your registry, memory and whatever, as well as you can use write protection as well.
Yes, SBIE gives a much greater deal of control than Chrome, and therefore is more secure more configuration options=more powerful/more secure (if you know what you are doing).

 

@CWS: that's not necessarily true. If the underlying mechanism of the sandbox isn't adequate, then it won't work well, no matter how configurable it is. Sandboxie's driver is AFAIK pretty good, but I've seen other sandboxes that are even more configurable - and don't work as well.

(It's also more a function of the OS than you might think. Security software that works very well on Windows 7 is often pathetically weak on XP.)

 

Fortunately, that's not the case with Sandboxie. I see SBIE V4 working very well in my W7 and XP as well as in friends and family computers who have Vista and W8. Usually, if they get an error or something is because they need to upgrade SBIE or they messed up a setting. Whats funny is that I never hear from friends when their AV is disabled or not working but if that happens with SBIE, I ll hear about it until I go see them.

Bo

 

But it is true, however you need to have a knowledge of your OS, Malwar and several other posters have helped me to enable start/run restrictions and internet access restrictions, as well as block access to all critical places on my Windows Xp Service Pack 3.
So, it is true after all.

 

Did you just miss or ignore something again, like my last 3 lines (aka most of the quoted post)?

Honestly, I can see why people as competent as Windows_Security, Hungry Man, et al stopped bothering to argue with you. You don't accept anything against SBIE that isn't 100% damning evidence (used 2 descriptors for a reason, the first one isn't enough).

 

That's their problem, not mine. I argue that tightly configured SBIE should be tested, not SBIE on default level, they ignore this, well everyone does.
You ignore that Chrome does not have configuration capabilities like SBIE, sure you could use AppLocker, SRP and Chrome's configuration as combo, however, I can use only SBIE to block access to whatever I need to-I can't do the same with Chrome alone, sorry.
Why should I have a bunch of other applications to protect myself if I can have only one like SBIE or DefenseWall or AppGuard for example?
It's a waste of time and money as well.
Rock-solid and simple security matters, not the complex and not the bloatware one where you have many security software applications which slow down your computer, rock-solid security and usability both equally matter.

 

Once again, what is tightly configured? State what should be tested and see how everyone thinks.
Did I ever say that? I only stated it has far more configuration than you think. Nothing is alone when you're running it on top of an operating system.
AppLocker, SRP, Parental Controls, group policies, and registry tweaks are built within Windows, and far from bloatware as you claim. It is in fact using less applications.
I really wonder how much you know about what's being discussed.

 

Because I'm curious and a bit obsessive, I tried breaking out of SBIE with the following settings:

- No immediate recovery for any files
- Drop rights
- IE is the only program allowed to run in the sandbox
- IE is the only program in the sandbox allowed internet access (yay redundancy!)

I'd assume this is a reasonable setup for someone with a registered copy of SBIE... Anyway I couldn't get out of the sandbox (un-updated WinXP SP3 notwithstanding), can't say I'm surprised.

I'd try with Chrome as well, but Metasploit's DB has precisely zero exploits for any version of Chrome whatsoever.

BTW, something maybe worth pointing out is that on Vista and later Windows versions, Chrome uses integrity levels like IE. But on Windows XP it uses a completely different (and much weaker) mechanism. On XP Sandboxie may be the stronger of the two.

Going the other way, though, you have issues of filesystem access. Processes in SBIE have to have *some* filesystem access or they couldn't run. But the renderer that Chrome sandboxes requires no filesystem access; in fact, the Linux version of Chrome chroots its renderer threads to an empty directory. The Windows integrity level mechanism isn't the same as chroot(), but again, it doesn't need to give the renderer *any* filesystem access.

Edit: not sure why I'm posting any more, I think I've forgotten what we're arguing about here.

But @CWS: take a look at this, please:
http://0xdabbad00.com/2013/04/28/exploit-mitigation-kill-chain/

 

Yes, I've read the posts and I don't really know how to respond because I'm not sure I see what the arguments are.

The research shows the limitations of Sandboxing on Windows. That's all.

Then people started discussing the efficacy of the research without a "proof of concept", which is typical and exactly the attitude that leads to defenders getting the **** kicked out of them every day.

 

If you use all that AppLocker, SRP, Parental controls or only one SBIE, the best thing is that it is all inside sandbox, which is another advantage as well.
Windows security policy is always welcome, but it doesn't match up on what AppGuard, or DefenseWall or SBIE can do.
Tightly configred depends on what/how exactly you configure it.

 

And all of those mentioned test are a fail because of the default settings-if SBIE was tightly configured with the help of users, than it should have been tested like that-tightly configured, since everything and everyone beats SBIE's protection with default settings.

 

That's all ok, but why SBIE has stronger protection is simple:start/run and internet access restrictions, as well as block access options-I mean really how can anything/any exploit/malware infect you-if it can't even start/run (it does not matter if we're talking about XP or later versions, rules are always the same)?
That's much more than Chrome offers.

The key problem with Google Chrome's browser's sandbox is using and relying on internal Windows security mechanisms. One sucessfull privilege escalation vulnerability exploitation-and your defense is broken, SBIE does not depend on this, and this is a key difference and a key reason why I have more trust in SBIE than in Google Chrome, because of this SBIE really is more secure than Chrome.
Similar comparison comes with the old GesWall and DefenseWall-Geswall also uses and relies on internal Windows security mechanisms, unlike DefenseWall which does not-because of these facts, I'd rather pay for DefenseWall than for GesWall, this is why I rather use DefenseWall because of this non-mentioned fact DefenseWall is more secure than GesWall-exactly the same situation we have with SBIE and Google Chrome.

Although I have to admit that I don't know if AppGuard is using the same approach-I don't know if AppGuard uses and relies on internal Windows security mechanisms or it is more like DefenseWall-I'll leave this to AppGuard users to respond.

You said:
"Going the other way, though, you have issues of filesystem access. Processes in SBIE have to have *some* filesystem access or they couldn't run. But the renderer that Chrome sandboxes requires no filesystem access; in fact, the Linux version of Chrome chroots its renderer threads to an empty directory. The Windows integrity level mechanism isn't the same as chroot(), but again, it doesn't need to give the renderer *any* filesystem access."

Answer: That is not really true, whenever I use my BankingBox for online banking/shopping, I block everything except firefox.exe which also has internet access-and guess what, it works just fine, so no it's not true that SBIE's files need system access and they can start/run, otherwise I would not be able to do any online banking/shopping, if everything except firefox.exe is blocked to start/run.

 

All of that is part of Windows, which all applications including Sandboxie run on. The proper comparison is system configuration versus one more software. All that hardening is integrated with the OS.
Sure, but it's a lot closer than you think. Nor does it need to for one to be malware-free.
That is true, but not some kind of necessity.

 

Fair enough, just don't think I'm relying on only SBIE, I have configured my XP as much as I know, and now I'm just fine, I use only SBIE for web-browsing and for removable drives (and I use read-only/write-protection option for all removable drives), of course I have disabled autorun on all of my drives in registry thanks some help guide on the net also I use NoAutorun software application for protection against removable drives infections as well, and that's pretty much all, of course I have tweaked windows xp firewall as much as I could and also I have tweaked my Edimax router on maximum protection with SPI+firewall protection (on maximum level as well).
And that's about it, I don't need anything anymore.
Simple, secure and easy on the system.

 

There is nothing wrong with your reasing capacities, only the facts you base it on are incorrect. You seem to ignore information provided by other Wilders Members, e.g. quotes of the developer of Sandboxie in regard to kernel exploits, statements of Wilders Admin who had contacted a few security specialists and ignored the link Guillable Jones so kindly provided you to understand how intrusion through content are delivered.

When you click on the PDF, you will notice a big square in the middle: it says MEMORY corruption.

Nowadays a lot of documents/objects contain both data and code, when visiting websites this data plus code is executed in your browser (HTML, Javascript, PDF, FLASH, XML, etc). Sometimes exploits even hide in the meta-data of a picture (e.g. png, jpeg or tiff exploits).

Many of these code+data formats are part of the rich content delivered to you on webpages. So when you allow a browser to execute in your application sandbox, you are allowing all those bits of code to execute. So your assumption when blocking 'other' programs exploits can't run is completely misses the mark.

 

The key problem is SBIE with default settings, everyone configures SBIE to block keyloggers-because it can be done, so why wasn't done in testing?
Why were not used start/run restrictions fro everything else that was tested in the first place for this or any other testing, whatsoever?
This is not called incorrect, it's called ignoring by Wilders members and ignoring by security testers!
The difference is huuge.

 

The question is if it can access the kernel, I'd like to see it myself with my own eyes. Tzuk also said other stuff as well, but people here are ignoring it, also he said it might be possible for SBIE to limit the damage-he didn't specify what exactly, but he mentioned this, he also said this:
As for questions about how some specific malware would act when it gets those kernel privileges. I can't answer such questions, I don't know how the specific malware behaves. It's possible that Sandboxie would interfere with correct operation of the malware, and it is equally possible that the virus would be able to break out of the sandbox.

I agree with Bo Elam when he said that "he doesn't care how they test Sandboxie. Those tests mean nothing, they are like a pre-season game. I only care what happens when the games count and is at that time when Sandboxie always comes out on top."

But how do you configure both SBIE, NoVirusThanks Exe Radar Pro and AppGuard combined-I thought this was impossible...

 

Have you been to outer space to see with your own eyes that the earth is a globe (not flat)? Without seeing it, you call me someone from the dark ages to not take Copernics findings for granted, because I have not seen it with my own eyes?