Sandboxie technical tests and other technical topics discussion thread

Rasheed, reading that statement, felt like an earthquake. Seriously, I personally don't care whats going inside the sandbox, I never had. I learned very early when I became a Sandboxie user that I can completely ignore whats going on inside the sandbox and need to only concern myself with what I take out of the sandbox and run unsandboxed. And thats exactly what I do.

That is part of the beauty of Sandboxie. You can browse or use an application for hours and hours and don't matter what you do, once you delete the sandbox, all is gone except what you recover. No popups or Windows with information. Sandboxie doesn't require any of that. In Sandboxie, none of that is important. I use my computers in a way in which it feels like I got nothing running for security. What you would like to see in Sandboxie, radically changes the Sandboxie experience.

Bo

 

Thanks for the link, Rasheed. It's quite informative, while not being too overly technical.

 

Not sure if it supports the latest version of SBIE, but you could try Buster Sandbox Analyzer. I'd vote to keep such functionalities separate from SBIE itself as well.

 

I don't know how can you conclude that.
I always keep saying bypassing Chrome will be a bit harder than SBIEed browser.

Can you post the link here? But I'm 100% sure you're misinterpreting that, because there's no real Chrome exploit which could bypass its sandbox.
Don't you know Chrome's sandbox is completely different from Chrome browser component? Or don't you know this sandbox is designed to contain Chrome exploit when it is compromised?
If you think more exploit reported is bad thing, YOU'RE COMPLETELY WRONG!
Especailly what I bolded in your comment is the worst mistake/misunderstanding, I have to say.
Actually it's good thing and this is one reason I think Chrome is more robust.
And please look into those vulnerability details. Most of them are DoS or info theft vulnerability, which anyway SBIE also can't protect.
There're some remote code execution vulnerability which by itself can't cause damage due to sandbox by Chrome.
Others are not relevant to Chrome on Windows.
I know 2 Chrome bypassing, the former is performed in Pwn2Own, which is done by determined and dedicated researcher and he had almost 1 year to prepare penetration to Chrome, and he also needed help of OS exploit to make real damage.
Honestly, I doubt that SBIE can stand for such a thorough analysis by highly skilled researcher, especially when SBIE seems to be build by C or C++ which is one of the most vulnerable language (I think Chrome also).
The latter is found recently, again it is quite advanced and tricky, also requires help of extension and sync. Common criminals will never find such complicated exploit by themselves.

Increased attack surface may be theoretical one though hypothesis that SBIE can stop exploit which bypassed Chrome is also just theoretical one, but not mystical because it's based on widely acknowledged facts that, more code means more attack surface and the best way to secure your code is make your code reviewed by as many 3rd party experts as possible (Chrome fulfill this but SBIE doesn't). And kernel exploit is not simply harder than common exploit. Kenrel exploit requires different knowledge than common one, and while yes there're fewer people who can write kernel exploit, that is no relevant when we're talking sophisticated APT.

Please never forget, not only CWS but other people here such as @Rasheed187 or @Peter2150, We're talking about sophisticated APT e.g. somehow national sponsored oragnization target CWS because maybe he have grave secret, as CWS care about that.

You can't make a comparison for hardness of kernel, kernel driver, and Chrome against bypass as they're different thing. Again, you seem to be confused.
Kernel exploit and kernel driver exploit is different, and the latter is recently becoming common way for rootkit to get system privilege.
Also as I said you can't compare the hardness of OS kernel exploit and Chrome bypass as they're different sort of thing.

So I understand you haven't actually read the paper, so also understand why you made wrong conclusion.
In this case who said that and what is their motivation is no relevant at all, unless they are lying. Do you think they're lying in all of their paper about this matter which is publicly available and it means any researcher can confirm or deny it?
I will agree with you about Bromium if it's another topic, but in this case what matters is just an technical detail.
We can even say that it's very natural Tzuk or Curt defend their work, but is this make sense?
However, well, I think ideally it would be better for keeping fairness if you can keep contact with Chromium dev, however unfortunately Chromium is not a commercial product and doesn't have such a support forum, and probably such question won't be welcomed.

He used cmd probably because it's very convenient compared to launching a server and visit it via sandboxed IE. And if he did it, that can make the research more complicated as he also have to consider and discard IE's own protection mechanism.
[EDIT: he did that just after SBIE bypass for Dell Protected Workspace, and it's obvious that using IE makes the study a bit more complicated. It's not the purpose of the study.]
Actually launching cmd is not necessarily, once compromised browser get the same privilege as the SBIE itself, it's almost game over. As he described, then he can directly attack the driver, or if he well know victim's machine he'll prepare special payload to migrate to another process outside the sandbox, which don't need launching cmd.

Attack surface reduction can never show it's role in real situation thanks to its nature. It's a kind of devil's proof.

You also misinterpreted what Curt said, he just spoke about user-mode hooks generally. The difference btwn user-mode hook and kernel-mode for bypassing is the former needs to take all measures to block bypass one by one, while the latter won't be bypassed unless attacker get admin privilege. Chrome takes all counter-measures so bypassing Chrome is very hard, and it have been well proven. But while Adobe Reader uses basically the same sandbox with Chrome, it's implementation is much weaker than Chrome so there was real escape for it.

 

I really can't get it at all.
What do you mean by "attacking Office documents is not impressive at all (actually, it's useless to be mentioned Duqu in the first place)."?
And do you really think Duqu is nothing special? Please read all artcles which Pete mentioned before (Kaspersky's securelist articles) before you speak.
I don't think you can still say such a statement after understanding what Duqu is.

And also bypassing kernel hooks (directly or indirectly) is much harder is just a myth. Even user-mode OS exploit bypassed SBIE in that notrious Bromium paper, but again who said this is no relevant unless there're lie or conflict.
Chrome will never implement kernel driver as it's very opposite of their principle, and I also hope they never make such bad dicision.
It can be said as a matter of preference, but I don't much like such a 'more, and more' approach.
Actually, if you already have lots of security software on the system, adding SBIE won't add attack surface as there're already prenty. Such system is however, while very well-protected against common malware, more vulnerable against sophisticated attack.
While I myself have had such a complicated protection, I'm recently more attracted by an approach like SELinux, though I know little about it.
It's based on beautiful mathmatics, simple in principle though is's actual implemantation seems to be complicated.
Compared to this, current Windows security environment lacks theoretical background and too complex, MS and 3rd party added anything they thought useful, and now it's a kind of chaos.
Maybe we're too accostomed to such security environment.
Imagine if Windows is quite secure and no malware have been found except some tricky PoC.
In that case, who installs AV? This is similar situation with Chrome exploit.

 

I already suggested that, and really hope they use BSA instead of request for SBIE to add bloat.
While Pete said it'll make SBIE more expensive, I think of another: It won't pay for Invincia as not many people actually want this.
I personally don't want Invincea to spend money to such a thing instead of other more important issues.

I think, from your post, it can even make new danger for novices as they might recover sandboxed component just because it didn't report any malicious actions.

 

Arguably, Freespace does implement a restricted kind of HIPS for those programs in the box. It detects abnormal activity and shuts down the box.

 

Completely agree, the requirement (for detection etc) is principally a business one, and so is the Freespace product. I'd suggest that we carry on as now (if they'll let us)!

 

Yes, I also like these kinda articles, because they are easy to understand. And I especially liked the "types of hooking" pic, that was exactly what I was looking for. You probably already knew this, but to clarify, on Windows 32 bit, all user-mode and kernel-mode hooking techniques are allowed. It's the same on Win 64 bit, except for SSDT, IDT and GDT kernel-mode hooking, who are all forbidden.

 

You are missing the point. It's not some HIPS that will bother you with "allow or block" alerts. From what I've seen, the HIPS inside FreeSpace (yes it already exists), will only alert if it has detected an exploit, it will then give you an option to terminate the attacked app/sandbox, or keep it running and monitor the attack.

And you don't have to, remember the on/off switch that I talked about?

Yes exactly, and I'm not saying that it should be implemented in the exact same way, it can also be a bit of a "dumbed down" version.

 

I never really was into this add-on. It would be handier if all of this was done by Sandboxie. And besides the ability to block exploits, it's also a handy way to get a picture of what modifications some app (that you run or install inside the sandbox) is trying to make. This way you can decide for yourself, if some app is most likely to be malicious or not.

http://www.invincea.com/2014/11/deja-vu-malicious-word-macro-attacks-re-surging/

 

Actually, if you ask me, it's a bad business decision. It has been 8 years since "Kernel Patch Protection" has been introduced (Win Vista 64 bit), and you don't hear any security company complaining about it anymore. In the last years M$ has worked with them to offer them the same protection options, resulting in security tools that are quite powerful on Win 64 bit. Think of Sandboxie, SpyShelter and HMPA, for example.

 

A general comment: Can you perhaps in the future try to say things with less words?

Here is an article just for fun: http://www.darkreading.com/risk/the-pros-and-cons-of-application-sandboxing/d/d-id/1138452?

 

I appreciate everything he's said so far.

 

The other way to satisfy those (including me) who want malware detection, is Invincea to make a FreeSpace edition for personal use, i.e. a cheaper license, and we forget about spawn a Sandboxie's evolved descendant.

 

Definitely a good point from you. Then we go back to Sandboxie realm xD, there is no other way.

 

You have to prove that bypassing kernel-mode hooks is not harder than user-mode hooks. It is simply well-known that if malware targets kernel-level, Chrome (and every other security software) since it uses user-mode hooks cannot do anything to protect against kernel, you have to have kernel-level driver.

 

No matter how hard it is to bypass Chrome, since it uses user-mode hooks, it will be easier to bypass it than software that uses kernel-level hooks for protection.
And if Google Chrome is so tough, as I can see from your posts, why do persist in claims that bypassing Chrome would be only a bit harder than SBIEd browser, unless it's Google Chrome under Sandboxie/sandboxed Google Chrome?

Do you mean by "...this sandbox is designed to contain Chrome exploit when it is compromised" that Chrome's sandbox is designed to contain Chrome's exploit when it is compromised?

Yes, this is the question that has tortured me for months, would any of these CVEs (so many of them, over 1100 of CVEs) bypas Google Chrome and its sandbox?

Cool, if it's really true that that you need so much time and so much resources to bypass Google Chrome and its sandbox, than Google Chrome is truly super-tough against all forms of exploits in the first place.
So, I ask you again and the same questions:
And if Google Chrome is so tough, as I can see from your posts, why do persist in claims that bypassing Chrome would be only a bit harder than SBIEd browser, unless it's Google Chrome under Sandboxie/sandboxed Google Chrome?

OK, I understand now, but I still don't know how can user-mode hooks help against kernel-level threats, you have to have kernel-level protection against kernel-level threats, user-mode hooks/protection cannot help against kernel-level threats.
Als, you're saying that bypassing kernel-level is equally hard, harder or easier to bypass than user-mode hooks?
Like I asked above how can user-mode hooks or any other form of user-mode protection and kernel-level hooks or any other form of kernel-level protection protect against kernel-level threats?

And again, if there is much needed to bypass Chrome, why do you keep saying that Chrome is only a bit harder to bypass than Sandboxie-according to your post right here, Chrome is much, much tougher than SBIEd browser, unless we're talking about Google Chrome under Sandboxie/sandboxed Google Chrome?

OK, so increased attack surface is a proven fact not just somehypothesis/theory, but if it's not harder to write kernel exploit why there are so very few people than can write kernel exploits?
I read that device driver vulnerabilities are much more difficult to exploit than many user-mode vulnerabilities and exploitation often ends up in a denial of service.

"Moreover, the exploits for kernel-mode drivers that do exist have proven to be very unstable because of the challenge of writing code at that level. "You can't stray very far from the path of what needs to happen within the kernel, or you're going to end up crashing the system rather than being able to gain access to it," Schulhoff said.
Because driver coding is complicated and tedious, there have not been many attacks on it, said Ivan Macalintal, senior threat analyst and researcher at Trend Micro. "We haven't seen much of that because device driver coding is not in the line of the script kiddies--unlike the usual worm codes that have been exposed publicly," he said.
In addition to kernel-mode drivers, Windows works with user-mode drivers, which run printers, graphics, USB devices and other hardware. That kind of software typically has fewer privileges, meaning that an attack exploiting them can be of lesser risk. Drivers are developed by Microsoft as well as by hardware makers, such as Intel.
http://www.zdnet.com/news/intel-driver-flaws-no-major-threat-yet/148447"

So this backs up what I said that kernel-level exploits are much harder to write than user-mode exploits.

So, what are key differences between kernel-level driver exploits and kernel-level exploits, and how so writing them is equally easy or equally hard as user-mode hooks?

When you're not an expert anyone can claim anything, so far I have not seen any Sandboxie breach so far-and that's what matters, however, you're right, Google Chrome is much more under attack-and Google actually pays hackers to attack, exploit Google Chrome and break its defenses.

However, how than we can know, how tough is Sandboxie, obviously not that tough, if by your previous posts, the guy who exploited Chrome needed so much time, help of OS exploit and resources and preparation time of at least 1 entire year to make real damage.

It means that no matter if Sandboxie had bypasses/exploits in the wild, it is obviously not a targeted software security program plus none has even tried to bypass it so far in a real world, plus you said Sandboxie is built by C or C++ which is one of the most vulnerable language.

But you also said that that Chrome also uses this language so what is the difference? Are Chrome's extensions problem, sync and Chrome by itself does not use C and C++ lanugages, only Chrome's extensions do (like Adblock, Ublock and etc.), plus sync, right?

Nevertheless, I will still try to ask Chromium about these questions when I find time.

Sorry for my bad english here: what do you mean by the former needs to take all measures to block bypass one by one, while the latter won't be bypassed unless attacker get admin privilege-what do you mean by former and latter?
Sorry for my bad english, I'm still learning it. I see now what is the difference between Google Chrome and Adobe Reader, it's all about how strong is implementation of each sandbox, and Chrome's sandbox is extremely hard, in PC magazine they say that Google Chrome is almost unexploitable (almost).

Regarding cmd.exe, like I said before Sandboixe can and will block it with internet access restrictions and start/run restrictions.
So, this bypass should be ignored when it comes to sandboxed cmd.exe should be ignored in the first place, since this was Sandboxie on default level.
If you in Sandboxie configure to block everything and prevent from access the internet and prevent start/run for everything that can be blocked and prevented to access the net and prevent from start/run and than test it, than I'd say, this is ok, there is a true Sandboxie bypass.

But you should find another way to bypass Sandboxie, you say in the last post by using compromised browser, so close it and it automatically deletes itself, if this does actually work than this is a true bypass-but what other bypasses maximum-configured Sandboxie 4.14 cannot protect against-this is what I ask you.
The only other bypasses that bypass every security software are kernel-level exploits/driver exploits and this APT you mentioned.
Rasheed says memory-based bypasses also.
What about against Google Chrome? Kernel-level exploits, exploiting chrome.exe and APT would bypass Chrome as well, so it depends how much exploits and how much effective/powerful exploits can exploit Google Chrome and how much the same powerful exploits can bypass Sandboxie.

Going by conclusion of your last answers, Google Chrome beats Sandboxie, not just by a bit, but Google Chrome easily and by faaaar beats Sandboxie (even 4.14 version).

Big sorry for this detailed questions, yes I admit I'm extremely tiring, but since I won't be free to post anything almost entire week, I had to write here everything that was on my mind-and big thanks in advance for your time, nerves and patience.

 

Potentially vulnerable language is a better description - depends how it's written and compiled. Personally, I feel better protected by software written by a strong coder (Tzuk), rather then the Byzantine and ramshackle creations of committees in big companies, written by the bored.

One of the good recent developments that Invincea has done for Sandboxie is the move to more up-to-date compilation, and that gives ASLR for free (as well as integrated language updates). It's also more amenable to tools/compiler settings to do code and bound-checking etc.

We cannot assume that Sandboxie (or any other virtualisation technology) is or will remain unattacked. It's true that, at the moment, some malware is testing for virtualisation (and restricting its behaviour rather than attacking). But it is possible for malware to test for the fact it is running in a Sandboxie sandbox and react accordingly.

My sense is that run-of-the-mill crimeware will exploit lower-hanging fruit (there's a lot of that) - but if you're talking APT, all bets are off and there are so many potential vulnerabilities, Sandboxie is not one I'm losing sleep over (exfiltration and data mining are, and Sandboxie can help with that).

If you want better, I don't see the problem with Live-Cd or pendrive approaches.

 

This will be my last response about this topic. To be honest, I don't want to spend more time for such a endless discussion, especially when it is no relevant for almost all of us.

Once attacker get the same privilege as the sandbox program, kernel-mode hooks are also bypassable. It's almost game over for both of user-mode sandbox and kernel-mode, though the latter may put some not-absolute obstacle.
However, it doesn't mean user-level threat can bypass user-mode sandbox easily.
But user-mode sandbox have to implement all measures to prevent bypasses, while kernel-mode basically doesn't care about such bypass.
Such implementation of course includes security mechanism of OS itself, and actually it is this mechanism that can make user-mode sandbox possible. Even kernel-mode sandbox have to rely on OS security on 64bit Windows.
Maybe this article also will be interesting for you.
http://www.malwaretech.com/2013/10/ring3-ring0-rootkit-hook-detection-22.html

I don't understand why you want to take things extreme way. But that's simply because Chrome is more thorougly analyzed by lots of people, not only experts but even DIY programmer. I know some actual cases that DIY programmer found serious vulnerability which even experts missed, the one case is relatively recently and it was about Android browser.
So it is more likely SBIE has more vulnerability currently unknown, but even so, attacker still have to reverse-engineer or fuzz SBIE and hove to find vulnerability. And I believe Invincea already have such audit process, so it must be also difficult for attcker. However, whatever effort Invincea made, it can't reach Chromium's degree. Also you know, Google have a big bug bounty program this is one more factor.

Yes, exactly.

As I said, most vulnerability (DoS or info theft) can't be protected either Chrome or SBIE, and some others are not relevant (e.g. vulnerability in Linux or Android Chrome, or Chrome OS).
About code-execution vulnerability, yes it can't damage by itself due to sandbox. If you want to make real damage, you have to use code-execution vulnerability AND sandbox bypass vulnerability, now I searched, and found 7 successful sandbox bypass case. I have to say, to avoid misunderstanding, this is good thing and I'm sure if SBIE is thoroughly analyzed by such many experts, there'll be at least as much bypasses. In fact, even researcher who successfully bypassed Chrome says "The Chrome sandbox is the most secure sandbox out there. It's not an easy task to create a full exploit to bypass all the protections in the sandbox. I can say that Chrome is one of the most secure browsers available."
BTW, as once you said TTF exploit can be prevented by blocking t2embed.dll, I point out most of those Chrome bypasses also can be prevented by modifying Chrome config or other conditions (some exploit need OS exploit or 3rd party app vulnerability such as flash)
Those links will satisfy your interest to some degree.
http://www.computerworld.com/articl...ches-310k-worth-of-chrome-chrome-os-bugs.html
http://www.computerworld.com/articl...st-winners-exploited-16-chrome-zero-days.html
http://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1.html
http://www.zdnet.com/blog/security/pwn2own-2012-google-chrome-browser-sandbox-first-to-fall/10588
http://www.esecurityplanet.com/browser-security/chrome-firefox-and-ie-fall-at-pwn2own-2013.html
http://www.eweek.com/security/pwn2own-2014-claims-ie-chrome-safari-and-more-firefox-zero-days.htm

As I already said, once attacker gets kernel or even just admin privilege, kernel-hooks are also bypassable.

Hey, please! Just take thing as it is.
I really can't understand why you always interpret things in such way, why my saying can be interpreted as "increased attack surface is a proven fact not just somehypothesis/theory"? Can any other member explain this? Maybe my English is so bad?
What I said was, "more code means more attack surface" and "best way to secure your code is to make it reviewed by as many 3rd party experts".
That is that. That can't be directly applied to sandboxie as that is just a principle. However, it is well possible that SBIEing Chrome can make new attack surface at least in theory.
And also I said "kernel exploit is not SIMPLY harder", again, my English is broken?
I didn't say kernel exploit is not harder or even easier, or maybe it's due to your English reading skill? I don't know, and need others opinion about interpretation of the sentence.
To answer your question, writer have to know Windows' kernel well to write kernel exploit, and this is different thing against common application exploit.
Basically, as I said in previous post, there're much fewer people who can do this. But I say it's not SIMPLY HARDER, IOW, theoretically it is possible even who can write kernel exploit can't write common exploit as they are different (though it's unlikely in real situation) there can be more sophisticated user-mode exploit than a certain kernel-exploit.
[EDIT: Replaced example with better one]

And keep in mind, attacker don't necessarily need to care about stability of victim computer. And there're already rootkit who use kernel-driver exploit to gain system privilege. So even common rootkit writer can do this, why you think those who we're discussing―advanced attacker in sophisticated APT can't?
Who found TTF 0-day vulnerability which is unknown in security world? That was such an attacker.

And can hardness for writing user-mode exploit apply to bypassing Chrome sandbox? No. Usual user-mode exploit can't bypass it, at most just cause code-execution which itself can't make damage unless it bypasses sandbox. And it is well proven how difficult it is to escape Chrome sandbox in all those events such as Pwn2Own or Pwnium.

Kernel-driver exploit is just an exploit against kernel-mode driver, but kernel-exploit means exploiting OS kernel. They are never equally easy.

Whether a software is widely targeted or not is not relevant to its hardness.
Yes, in real situation it makes sense and this is a reason some person like not-popular browser such as Presto Opera (though it's abondoned).
But that is completely different story from it's hardness.
[EDIT: Also don't forget we're talking about sophisticated APT. In this scenario, usually attacker knows the victim's system and network and even human-relationship well, and make customized attack to penetrate ONLY the victim.]

The difference is, as I said again and again, Chrome is reviewed by many experts and DIY programmer.
As to extension and sync, what I mentioned is the most recent Chrome sandbox escape, which attacker(resercher) needed help of extension and sync to bypass it. In this case, those extension and sync are used as additional attack surface (as already said, some other Chrome bypasses also needs such an additional attack surface like kernel vulnerability or specific Chrome function which can be disabled from setting).

The former means user-mode hooks, the latter means kernel-hooks.

I said attacker don't necessarily launch cmd.exe to bypass sandbox. As long as you allow browser to launch (of course you shouldn't block it if you want to browse), it will be bypassed, because attacking kernel and gets system or kernel privilege doesn't involves start/run and once the attacker get the privilege, it's almost game over.

Well, memory-only malware can send info to e.g. C&C server, but as to this, you can defend yourself to some extent (not perfectly as browser itself may keep sensitive info) by blocking access to all personal or sensitive files/folders and registry. Also best practice to empty all sandbox before sensitive activity ensures more than 99.9% safety against this type of attack and actually much more.

I think you don't have to hurry so much, but this is my last answer because, you see, I also have my schedule and other thing, same as you.

It is well possible that what I wrote was wrong or pointless, however I wouldn't correct as I want to stop taking about this.
Thanks for your patience and sorry for my bad English too.

 

I'll try, but please understand my English is heavily limited and I have to rely on dictionary and translation add-on so much to write/read those posts.

BTW, the link is very intersting. Thanks for the info

 

Well, from my standpoint you have a very, if not, excellent English writing. My native tongue is Spanish and I can assure you I don't speak it or write it at its full potential, and no one does. This is true for any person in the world and their own language. Congrats!!!
btw I have a college degree, studied English language since a little kid, and still learning. But I don't make use of translations add-ons, you do and you do it pretty good!!! Better than mine!!! lol