Sandboxie technical tests and other technical topics discussion thread

Yuki, according to Invincea, to test Sandboxie......Bromium used an unpatched version of Windows.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&p=103163#p103163

Bo

 

Hi all,

Not sure if this is the correct section (technical tests seems to fit) but just as a heads up I believe I've found a sandboxie bypass which could be used to compromise a system. Currently only tested on 4.14. I'll be sending the details through to invincea but in the meantime would suggest that you don't allow sandboxed apps to run as administrator via UAC (I know.. common sense, but still.). There's also a similar issue which doesn't require admin rights via UAC but the potential for compromise is much much lower.

I still love sandboxie

 

Really, I believe is imperative when you make a claim of this nature to share all possible info regarding the bypass. Don't get me wrong but you could be posting this for uff! don't want to sound rude... I hope you understand.

 

I understand where you're coming from and I apologise for being so vague, but I thought the general consensus was that it was more important to give developers the chance to release a patched version first? Truth be told im a long time lurker and thought a heads up was in order for those who may be so bold as to test questionable apps in sandboxie on their main OS (probably doesn't apply to many of us here).

 

Agreed. For me and some others, skepticism and science are the only tools to understand the world as it should be. Sorry for the off-topic.

 

Pete, I firstly want to clarify 2 things.
1. Most of us won't come across such advanced attack at least in foreseeable future and thus it can be said no relevant, IOW those discussion shouldn't harm your trust on SBIE, or you shouldn't feel fear of this.

2. Then why we discuss this? Answer is simple, because it is security forum here. IMO, most of Wilders member's setup are just overkill. Me too, you too. I believe if I remove some of products from your (Pete) setup, still I have 100% protection against all common malware. For senior member, having almost 100% protection against them is almost common sense. So what we do next? Then, we take 0day exploit (which to be honest most of us won't come across), unseen possible future threat, and advanced threat like one only seen in targeted attack. Now, common malware testing become no use as they don't represent such threats. Now technical detail matter rather than fact that the product can protect you from known threats. Now security is no more easy thing, though originally and essentially security should be easy. We are in such situation, so we have to switch my brain btwn practical, cost-performance aware one (to explain things for common people) and theoretical, paranoid-like one (to discuss things with senior member or techy people).

With enough effort, any security can be bypassed BUT what matter now is how hard it is. Even most targeted attacker are cost-aware so if the first target is robust enough they may shift to next target (of course it can't apply to every targeted attack). What important in the report is not about they could bypass, but they ranked how hard it is for all tested products and all tested threats which include user-mode exploit too. And also they confirmed double-sandbox don't make another obstacle at least against kernel exploit. And if their motivation matter, it means you haven't changed your viewpoint to academical one, you have to distinguish ("distinguish" don't imply "ignore" or "not aware") intention and your feeling, emotion, from the fact. They didn't turned off any function, they just tested SBIE with default setting as it is natural. Sure if they tested SBIE with possible maximum settings, I welcome it but there's no valid reason they should do so and determining "maximum" is not so easy (should they make giant list of access block?) Also I haven't seen ACTUAL challenge by Invincia, I heard several times about it and the paper, but that is not actually technical challenge, rather more of a feature comparison.

I suppose your search engine is different from mine (yes, even 2 Google don't reply the same result) as I can see many article about kernel exploit on Xp and somehow don't see much about Bromium. About you see lots of Linux articles, it's not because kernel exploit matters more on Linux. Actually I see same thing when I search for user-mode exploit, this is because many of exploit study are done on Linux (some of them can be applied to Windows) and competition like CTF (Catch the Flag) are usually done on Linux. The fact is it's not uncommon to hear about kernel vuln in Windows, so what matter is whether white hacker find it first or black hacker, but it is said even black hacker don't want to "waste" kernel exploit so they reserve them for possible future use.

 

So you still don't understand Chrome sandbox architecture? Chrome renderer don't have access neither to driver or any file/folder you listed. And okay I'll give final example to illustrate this matter. If you donwloaded, say, setup.exe in sandboxed browser and want to access the file (either read, write, or execute) you have to previously allow that access to entire download folder (or whatever folder you will download file) in SBIE. In Chrome, renderer never have access to entire folder. After you donwloaded setup.exe, only that file can be accessed in restricted manner because broker dynamically make that access policy which allow only permited access to permited object (in this case, setup.exe). Assume installer.exe have been in that folder before all of these things, in SBIE if you allow access to donwload folder, sandboxed program can access either setup.exe and/or installer.exe but in Chrome that renderer which need to access setup.exe can't access installer.exe. These are somewhat explanation sake and not exactly correct (dynamic rules are bit more generic), but I think it's enough.

What do you mean by "targeted"?? It seems what you're saying is not real attack, but it should be called as audit or penetration test. Real attack made by common criminals are driven by money, so they target widely used program such as major browser or flash or MS Office. And if they employed outside efficient researcher or organization to investigate their product, don't publishing that fact is simply their misjudge/failure as all people who understand security will be put more reliance on the product if it was published. No, it's not better to keep silent unless that audit was just by their friends with no or quite cheep price. Some other software actually publishes about audit and its result.

 

That's not matter, because finding new 0day exploit is not easy it's common practice to use old exploit for pen test.

 

First of all, welcome to Wilders, Lumikai!

No need to be skeptical! It's not uncommon or shocking thing, I though last SBIE bypass was found in MalwareTips and as I said earlier I know a man who happened to find serious vuln in Andorid browser. I'm glad that Lumikai know correct way to treat 0day vuln. Yes, you firstly have to report it to dev and never disclose any details until they publish official patch! This is what is known as responsible disclosure, and it was even better that you shared workaround for us w/out disclosing unnecessary things. We have to welcome him warmly as he try to contribute to one of our favorite program to make it more robust, and thank God that he was not black hacker.

 

What exactly is installer.exe compared to setup.exe? And I thought integrity levels are the ones which are responsible to prevent such scenarios, besides the fact is Sandboxie also uses Windows integrity levels as much as Chrome does, so where is the difference, if both SBIE and Chrome use integrity levels?

Also, people mention, and also Ilya on DefenseWall website mentions that Google Chrome and its sandbox greatest weakness is that SBIE is relying on Windows security mechanisms. One successful privilege escalation vulnerability exploitation-and your defense is broken.

Also, please answer this: Curt, as far as I know, says that SBIE does not rely on internal Windows security mechanisms (there was a thread on Sandboxie forums), while like I said above Google Chrome does-and that's why SBIE, at least, theoretically, should be more secure than Google Chrome-what do you think?
Is Ilya wrong about what it says on DefenseWall website about Google Chrome relying on internal Windows security mechanisms?

I mean, in the way hackers/security researchers are paid to find vulnerabilities/exploits inside Google Chrome and its sandbox.

 

Just for the record Yuki, I asked Bromium personally to test Sandboxie (version 4) again with maximum settings, they responded me later that it did not have any effect at all, or something like that Sandboxie was bypassed one way or the other, despite security enhancements in version 4 and despite the tightest configuration settings.

 

Nice info from yours indeed. And good news... at least for me. Thanks a lot.

 

Assume you launched sandboxed browser, downloaded installer.exe from a.com, later you downloaded setup.exe from b.com, and now you need to access setup.exe but don't need to access installer.exe. In SBIE, you have to previously allow access to download folder (strictly, you have to exclude your download folder from access restriction because you need to access a file you will download. If installer.exe was on the folder before you launch browser, you can set access block for installer.exe but it's not the case now). In Chrome, broker process dynamically make access policy and renderer can access only setup.exe, but can't access installer.exe. In short, Chrome allow dynamic and more granular access control which SBIE don't provide. And in this case, what responsible is not IL but restricted token. I don't explain more about it, that is what you have to learn by yourself.

Oh, my... I can't hide sigh.
Firstly DW is only for 32 bit OS where Kernel Patch Protection don't matter. Next, maybe "people" include him?
http://forums.sandboxie.com/phpBB3/viewtopic.php?t=11788
obviously he lacks many basics in security, but same can be said against me and I only post the worst one.

The source link is dead so I don't know original source, but his interpretation is terrible. That's not design flaw, that just means security is job of other parts or function, namely OS security mechanisms. For security respect it is safer to forbid most of IPC and its hooking but that means the browser become unusable crap. Remember I firstly said kernel hook by SBIE will be more for compatibility and usability in early post here. I know this type of argument is hard to understand for some people as I see same confusion in discussion about UAC. See this thread and try to understand why UAC is not security feature.

I don't think Curt actually said SBIE do not rely on Windows security mechanisms, at least Tzuk didn't say.
http://forums.sandboxie.com/phpBB3/viewtopic.php?t=14454
I suppose Curt just said SBIE (also) uses kernel hook, but it doesn't mean SBIE don't use OS security and it seems the reality is opposite. From the link, you'll find SBIE use not only IL but job object too. Also it uses desktop isolation (anonymous logon user), all of them are OS security. This is quite reasonable because thanks to KPP, 3rd party dev no more can use direct kernel hook, but have to rely on what Microsoft provide. So I interpret Tzuk's saying "There should be no change" as he moved what previously done by kernel driver into mechanisms or API what MS provide. It doesn't mean it became weaker, OS security are finally supported by kernel and IMO less 3rd party kernel work means less attack surface as most 3rd party kernel driver won't be audited in OS kernel's degree (you can find many serious vuln in 3rd party driver).
As to priv escalation, once attacker gained admin or system priv he can bypass any security program on Windows. I admit it's "theoretically", but there's no clear evidence to deny this theory while are many empirical supports (I don't call them as evidence). I completely agree with GJ about this, except he use word theoretical and practical with different meaning. (BTW it's not necessarily the case on Linux where even admin can be restricted via LSM, and similar thing can be said to Windows in domain but it's out of scope for this discussion, I focus only on home environment.)
Maybe any 3rd party security vendor claim they offer better security than OS, but that is as if they ignore possibility their software will have more vuln.

Yes, theoretically combining kernel hook can be more tough, but it also means more risk. I mentioned about dll when we discussed about added attack surface, but there can be more attack surface in communication btwn SBIE and Chrome, or btwn any other component SBIE exposes to Chrome and Chrome's process when you sandboxed Chrome. Basically I doubt when 3rd party vendor claim they offer better security than native function. Yeah, same goes for Bromium, I'm not surprised at all if their product have worse vuln than OS kernel.

As a hope that it will satisfy you and you don't ask same or similar thing again, I'll summarize pros and cons about sandboxing Chrome, but remember the biggest benefit is downloaded contents, privacy, and other purpose such as testing while largest demerit is incompatibility.

Pros against exploit:
SBIE won't be targeted by criminal for mass attack. This is what you misunderstood my saying, but you have to know economy in cybercrime (again, this is what you should learn by yourself). OTOH, Chrome have good enough reason to be targeted. Whatever robust a product is, when attraction to attack it excelled the hurdle it can be attacked. And in such scenario (won't occur for a time) sandboxing Chrome might save you as attacker have to adopt his attack code to what they want to penetrate and SBIE add some twist againt this. So even if SBIE itself was less secure and less robust, and/or even if you disabled Chrome sandbox, this kind of economy can change the game.

Cons: Sandboxing Chrome can add additional attack surface. From Chrome's point of view, any added code is potential risk, and they can be used to break out its sandbox or escalate priv especially when it is kernel mode component.
Also SBIE can mess up Chrome's security architecture. At least it runs broker process in untrusted IL, I think it is not good for Chrome although IL itself don't make security boundary. These can matter in targeted attack where above discussion (SBIE won't be targeted) can't be applied.

I wonder it is time that I had better leave this thread...(._.)

 

Thanks for confirming.

 

OFF TOPIC:
I'm not sure whether I should post it but...
I really don't want to frighten what bo called lucky guy. Now I've read what I wrote and found it is well possible unless that guy read this thread from the beginning and correctly catch the context (quite unlikely).
So I will be lurker on this thread and seek to how to control myself.

 

NO!!! Yuki, please do not just lurk. Between Bo and you I have learned so much (except I am still trying to understand all of it ) I beg of you, KEEP POSTING!!

Acadia

 

I agree with Acadia, Yuki. Stay put and keep posting about SBIE.

Bo

 

Could`nt agree more.

This thread is definately a hot bed of discussion on the subject of sandboxing and very informative indeed.

To all participants please keep up the cut and thrust as I`m sure there`s enough lurkers here already.

Regards Eck

 

No problem, I tend to look at the world in the same way. If it helps the following unlisted youtube video was linked to invincea when I passed on the details (bypass demonstration): ~ Link Removed As Per YouTester Policy ~

The details have now been passed on to Invincea so rest assured the problem won't be around for long.

Appreciate the kind words Yuki.

 

Can you bit explain the bold sentence, is this the same what I was trying to say (And in such scenario (won't occur for a time) sandboxing Chrome might save you as attacker have to adopt his attack code to what they want to penetrate and SBIE add some twist against this.): sandboxing Chrome can only make more difficult for attacker to bypass both Chrome and Sandboxie!

But what did you mean by:
"So even if SBIE itself was less secure and less robust, and/or even if you disabled Chrome sandbox, this kind of economy can change the game."

Did you mean here in this sentence, that it's better to use Google Chrome and its sandbox without/outside Sandboxie, because Chrome is tested and proven extremely tough sandbox, while Sandboxie is not?

But shouldn't adding Google Chrome under Sandboxie's protection make things much more complicated for any attacker who adopts his attack code to directly or indirectly bypass both Sandboxie and Chrome (I'm thinking of 2 scenarios: 1. Google Chrome and its sandbox are under Sandboxie's protection, and 2. Google Chrome and its sandbox are outside Sandboxie's protection)?

First of all my apology, I was writing so fast that I wrote wrong: When I wrote the following:
"Also, people mention, and also Ilya on DefenseWall website mentions that Google Chrome and its sandbox greatest weakness is that SBIE is relying on Windows security mechanisms. One successful privilege escalation vulnerability exploitation-and your defense is broken."

What is meant is this:
Also, people mention, and also Ilya on DefenseWall website mentions that Google Chrome and its sandbox greatest weakness is that Google Chrome and its sandbox are relying on Windows security mechanisms. One successful privilege escalation vulnerability exploitation-and your defense is broken.

Questions: Also, does Chrome's broker run on untrusted integrity level? You said, that Google Chrome's renderer does run on untrusted integrity level, but I don't know about the Chrome's broker, I think it runs on low level or maybe even medium level.

Second, here is the thread where Curt mentions that SBIE does not rely on internal Windows security mechanisms, although it doesn't make any sense to me, if SBIE is actually using internal Windows security mechanisms:
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=4&t=19486&start=15

Big thanks in advance, again.

 

Curt@invincea:

ClosedFilePath=C:\WINDOWS\system32\win32k.sys
ClosedFilePath=C:\WINDOWS\system32\drivers\

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=19163&sid=04a3c70110bd3d8a184cd902a6e93f1d

 

Guys...truly appreciate your kind words. I found I can't control my writing, can't ignore questions, can't choose careful words, etc. so bit depressed (not seriously).
I try to stay on, but seek how to keep proper distance.

 

Hi, Pete! Really thank you!
Now writing reply for CWS.