Sandboxie technical tests and other technical topics discussion thread

No.

No. Maybe I had to say "even if SBIE itself was less secure and less robust, this kind of economy could change the game regardless whether you enable/disable Chrome built-in sandbox" so that you can get correct nuance of "even if". I'm not necessarily 100% believe Chrome sandbox is more robust than SBIE though it well can, but what I wanted to emphasize was that attraction for attacking a product matters.

An attacker doesn't need to bypass each sandbox one by one. And we're now assuming targeted attack (especially APT) because such attack surface can only be matter in it, so also assuming the attacker already know victim always use SBIEd Chrome (it's not uncommon that attacker know what OS, products, network, human relationship, etc. the victim have in APT). What he want to bypass is neither Chrome nor SBIE, but "SBIEd Chrome". And from what I've seen, in advanced exploit like seen in APT complicatedness don't stop attack, however most of those attack need some added attack surface or special condition.

Already answered earlier.

He had to say: Features like redirecting file/registry writes into the sandbox are not part of Windows security.
That is why I initially said kernel hook by SBIE will be more for compatibility and usability. Redirection is not security feature. It's the same pattern as that Chrome's IPC hook is not security, or that UAC is not security, oh, one of Curt's comment can be interpreted that he also thinks UAC is security feature, though that can be said matter of viewpoint, but you have to distinguish security feature and consequentially accompanied security effects. For the security sake it is better to forbid all access rather than redirection. As DR_LaRRY_PEpPeR showed it can be and actually done within OS security mechanism w/out kernel hook. While originally sandboxed process don't have any access right, SBIE additionally allow some access for usability and compatibility (and if it was write access, redirect it). For this purpose, SBIE have to interact or communicate with potentially compromised process which may send specially crafted message to exploit SBIE (or any other component SBIE exposes to the process). Considering originally such interaction is not necessary (IF you don't need that usability and compatibility), it's nothing more than attack surface for skilled attacker who examined how each sandbox works and eager to exploit them.

About bolded part, also Chrome will protect you from most of user-mode OS exploit. Bromium's test also includes one, though finally he bypassed all sandboxes, he admitted Chrome was the toughest.

It makes sense that SBIE can restrict even admin, but there're history of bypass HIPS and even kernel-mode hook can not be 100% bullet-proof especially when attacker have enough resource, skill, and zest. OTOH, once program running in kernel-mode was exploited, the results will be catastrophic.

I usually don't look through SBIE forum but now I found FleischmannTV's interesting post.
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=19260
Maybe I had to run Process Explorer by myself, but I already lost interest on it...anyway it proves SBIE actually mess in Chrome's security, via job object and SID. While SBIE uses anonymous user, Chrome uses null SID except for logon SID. Though anonymous user is very well restricted, null SID is more severe.

These attack surface and interference can make bypassing sandbox a bit easier for such dedicated attacker, however I'm sure 99.9% of us will never be involved in such attack. This tzuk's statement hits the nail on the head.

Though we won't see Chrome bypass for mass attack in foreseeable future, still SBIE can save you from donwloaded object or social engineering. I know many people here tend to think "I'm not such stupid.", but I don't understand. IMHO such arrogance can someday cause you to get the your own medicine.

 

Another thank-you for all the discussion and contributions here. I value them.

My take is that confirmation bias and any arrogance is the most dangerous position to be in, and that a questioning and humble attitude is better security. So the discussions here helps that. Not that we will be "right", but that we are all taking the best calls we can within the constraints we have, with the knowledge that people share.

I remember literally the most shocking episodes I've had in my life (e.g. attempted self-electrocution with a plasma screen!) - have been when I thought I understood something well and was complacent.

 

More about sandboxing Chrome, increased attack surface, etc, with comments from Tzuk.
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=11788&sid=491b48bb3a100f9b27b13dd772eeefbe

Bo

 

Since there's been some discussion in this thread of the real-world usage (or lack thereof) of kernel-mode exploits, I thought some of you may be interested in this non-targeted usage:

From CryptoWall ransomware variant has new defenses:

 

Interesting, there's a link from Cisco with in-depth info: http://blogs.cisco.com/security/talos/cryptowall-2

 

Ransom-ware will always fail inside the sandbox, because of virtualization and isolation.

Can you give a little bit info about this bug, what area did SBIE fail to protect?

 

I guess you could say it allows for the creation of files outside the sandbox. Depending on sandboxie setup a sandboxed application may create a file in the all users startup folder for instance which would run on next reboot.

The bypass is just a protection oversight, it's not a flaw in sandboxies code.

I've had word back from Invincea that the bypass is going to be blocked.

 

Since I don't have a sample of this, I tried a public POC for CVE-2013-3660 in a Windows XP virtual machine against Sandboxie 4.14. The POC was able to increase the privileges in a limited user account, but for the few things that I tried, the actions were either contained in a sandbox (example: copying a file to \windows folder) or prevented (example: adding a new user account via "net user" command).

So even if a kernel exploit is successfully used within a sandboxed process, it doesn't necessarily mean that Sandboxie has been bypassed.

 

Hi Mr Brian, what you saw is pretty much what Tzuk said in the quote below.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=12029

Bo

 

Don't forget that vuln was patched more than a year before. Correct patching eliminates nearly all ITW exploits.

Actually that was expected, IOW you were near to goal, but still not in the goal. you can see in the 1st kernel exploit test by Bromium they explained "an attacker needs to do some extra work". In the next test against Chrome, simple TTF kernel exploit was not enough for reliable RCE. For them these will be easy task, but for me it's not. This requirement of expertise is part of reason I'm not inclined to test it by myself.

 

You said:
"While SBIE uses anonymous user, Chrome uses null SID except for logon SID. Though anonymous user is very well restricted, null SID is more severe."
So, here you were actually trying to say that Chrome's null SID is much more restrictive than SBIE's untrusted integrity level/anonymous user, right?

I don't know why do you hesitate to say/admit that Chrome's sandbox is (far?) more secure than Sandboxie, but everyone who reads your posts should get the impression and conclusion, at least this is what I concluded, here is my detailed and final conclusion-please, Yuki, show me my mistakes, where I'm wrong:

Chrome's sandbox is more restrictive than Sandboxie, which means Chrome has (far?) more secure sandbox than Sandboxie (plus you said that security researcher had 1 year of prep to bypass Chrome's sandbox, plus he had help and knowledge of OS exploits that enabled him to bypass Chrome's sandbox-that's how tough Chrome's sandbox is-Sandboxie is not that tough, it would certainly not need entire year of prep to bypass Sandboxie with the super-tight restrictions combined with OS exploits, plus like you said Sandboxie does not block all access to entire Windows file system like Chrome's sandbox does, including drivers, kernel32.dll and win32k.sys and all other drivers and all other files/components/exes/dlls and everything else in entire Windows computer system) however, this is all completely nullified by facts when you consider that Chrome has unprotected java (outside Chrome's sandbox), opening, running, downloading and testing files, and social engineering, opening and running pdf readers, Microsoft office documents, flash players and similar-none of these mentioned weakpoints Chrome's sandbox cannot protect against in the first place, plus you need something like NoScript for Google Chrome if you take facts that most common infection come from downloading, running and opening files, social engineering, pdf readers, java, flash players, Microsoft office documents and similar-this is why Google Chrome's sandbox is more restrictive/more secure than SBIE (based on all your posts, so far), but overall it's still better and actually more secure to run Google Chrome inside Sandboxie, because of Chrome's weakpoints (mentioned above) that are not protected by Chrome's sandbox itself, and those weakpoints (mentioned above) that Google Chrome has are the most common attack points in the first place from which people get infected at least over 99% of the time-this is how I understood this after so many posts from everyone, not just you-and this is why my final decision stands still and this is why I will always run Google Chrome under Sandboxie (with all of the start/run and Internet access restrictions as well)-this is my final conclusion.
I'm sure that this is what you were trying to say the entire time while you were posting answers to me and to others when it comes to Google Chrome and its sandbox.

Since you already gave us link to Sandboxie's forums where FleischmannTV actually 100% proved that SBIE does actually mess in Chrome's security via job object and SID, FleischmannTV said that if you run Google Chrome inside Sandboxie, this job object does not exist and now Chromium processes can create child processes unless you apply start/run restrictions and once you have applied these restrictions you get the same as you would have gotten before without Sandboxie.

However, like you said Yuki, this is not true, because you already said in previous page there are things that SBIE cannot block no matter how tight your configurations inside Sandboxie are, because like you said: Google Chrome, does not have access neither to driver or any file/folder or anything else in entire Windows system. SBIE, on the other hand, like you said Yuki, cannot block all access, SBIE cannot block drivers and those components like kernel32.dll and win32k.sys-Google Chrome does not have access to either kernel32.dll and win32k.sys-right, Yuki?

After you explained everything, you posted Tzuk's post here:

I truly apologize, Yuki, I truly don't know what you and Tzuk meant here?
Could you give me more insight?
Did you mean it's useless to wait SBIE being exploited, but SBIE itself protects against other exploits that are very active/very frequent-couldn't we say the same for Google Chrome-with and without Sandboxie's protection?

Anyway, regardless of what you and Tzuk were trying to say, the main reasons I will use/run Google Chrome inside Sandboxie are downloading and testing files and social engineering-yes these 2 worry me more than anything else (I had to admit that).
It was not the first time I went on webpage I thought it was safe and I saw fake antivirus saying that I'm full of viruses, I have to admit I will listen to you and Peter and stay with Sandboxie sandboxed web-browsers (Internet Explorer, Mozilla Firefox and Google Chrome).
Than there was so-called, police virus which demanded me to pay 500 dollars (that was virus created in my own country), yes I had those tricky situation (anf the problem was whatever you click you will get infected in that website, even if you close your web-browsers)-against these nastywares Google Chrome and its sandbox simply cannot protect against, Sandboxie can and does protect against all of these mentioned all the time.

I don't know, maybe, just maybe something like NoScript for Mozilla Firefox should do the trick, I use UBlock for Google Chrome-I have to ask someone what is the closest thing in Google Chrome's add-ons when it comes to NoScript for Mozilla Firefox?

 

I just wanted to inform what Ilya said on DefenseWall webpage is the that since Google Chrome relies on internal Windows security mechanisms, it should be protected by DefenseWall (because of privilege escalation vulnerability exploitation)-but from what I read on this forum, if you bypass internal Windows security mechanisms, there is no way DefenseWall, AppGuard, Sandboxie or any other security software application will be able to protect you-this is why I don't know why did Ilya post this on DefenseWall webpage in the first place, am I right or wrong?
DefenseWall, regardless, if it does not rely on/or not use internal Windows security mechanisms, cannot protect against privilege escalation vulnerability exploitation in the first place, because DefenseWall cannot protect against compromised Windows, right?
Big thanks in advance, Yuki.

Also, I truly don't understand why Curt says that SBIE does not rely on internal Windows security mechanisms, but it is using them and it does not rely on them?
What's the difference between saying "relying" and "using"-if you use something, it means you rely on it, right?
You don't rely on it, if you don't use it; and you don't use it, and if you don't rely on it?
I mean you can't use something, if you don't rely on it in the first place.

 

I recommend uMatrix. It is though more than NoScript. There are hosts file blacklists and it has scopes other than global unlike NoScript. And other options not existing in NS. uMatrix does not come with the safest initial options, but rather made in my opinion too easy for the new users. The learning curve is deeper than with NoScript.

There are other Chrome blockers but I think they are less than NoScript.

 

BIG THANK YOU FOR THIS INFO, JARMOP, IT WILL DEFINITELY HELP ME, I will download it right now!!!

 

I never understand why you like to take things in extreme way. anyway, anonymous user can't change system settings, can't access your user data, so it's already well restricted but still have some access which vary on your setting such as EveryoneIncludesAnonymous registry value. OTOH, null SID is non-existent or shouldn't exist user and as described in Chromium sandbox explanation, as long as root directory have non-null security descriptor renderer don't have any access right. So it's more restricted only in an extent that anonymous user have access which depends on setting.

That means my writing gives reader false intention, maybe due to my lack of skills or carefulness, but didn't you admit it is "in theory"? We can't speak for sure that Chrome is more secure until trying to break both programs by ourselves or clear evidence is presented. Nobody know how much effort is needed to bypass SBIE as nobody tried it, as to Bromium they bypassed both w/ a little to mediocre effort, thanks to kernel exploit and already available resource (including the first Chrome bypass method). All we can do now is guessing from what we know unless you have enough skills to test it by yourself. Also to be fair, Chrome also allows some access. But the difference is they are determined by dynamic policy which allows Chrome to make more granular and strict access control.

What facts? why nullified when they are different thing? Firstly, just want to make sure that in current Chrome all plugins makes prompt when they try to access PC w/out sandbox, and if you enforce sandbox all plugins are either sandboxed or can't run at all, java should be no exception. And PDF document will be opened in Chrome's built-in pdf reader which employ sandbox.

I said what facts, because most common infection come from drive-by download which leverages old patched vulnerability, not from way you mentioned and "over 99%" statement is wrong, I wonder where you draw that number and just as a warn you have to be careful when you use extreme expression like 99, 100, 0, 1%, or words like "always", "perfectly", etc. Also I don't count them as a weakpoint, they are just out of scope for Chrome which is never security product, but still Chrome care about such attack vector to some extent by its safe browsing and download protection.
But yes, the best benefit comes from SBIEing Chrome are those uncovered or out-of-scope attack vector and privacy concern, but don't shrink down SBIE to just a security product, it can be used in many other ways depending on your creativeness, this is what I very like about SBIE among others.

I don't know what is not true. Restricted token is different from job object. It seems it's better you first search for and understand those each Windows security mechanisms because I see some confusion in your post about those mechanisms.
After you explained everything, you posted Tzuk's post here:

What tzuk said is IMO simple. SBIE might have serious vuln in it. But possiblity that this vuln is exploited will be extremely low, not because finding this is extremely difficult but, consider how much merit does it give for common attacker? Do you know Chrome usage is literally billions (I say usage, not user number as one person cam use many Chrome e.g. for desktop, for laptop, and for corporate)? This is quite attractive for criminals as they are driven by money. But does attacking SBIE makes such much interest? You see Rmus posted he could find only 1 ITW exploit against Opera, but I guess the number of Opera user is still far more many than SBIE. Of course, it's different story in targeted attacks where number of usage don't matter, but then how much possiblity you have that you will be targeted? I think I'll never be targeted.

"Rely" means if it is bypassed, it's gameover. "Use" means it's not gameover. Let's take Curt's example of poor Boeing 747, well, I'm familiar with airplane, and in that example compromises all OS security is like breaking 3 of 4 engines. Yes, still the plain can manage to continue to fly but it's in very dangerous state. It can't go straight as usual, and need to land on nearest airport as much as possible, still whether landing will succeed or not depends on skills of pilot and co-pilot, and other damage against e.g. fuel control, avionics, and/or ACS.

[Off topic: ] BTW, those conversation will never end as you'll never be fully satisfied. As I said earlier, only you can convince you and until you learn things from fundamentals, you can never reach or approach the truth. Things will shrink down to just a matter of trust, and what you say won't be persuasive to others. I have to say massive googling should have eliminated at least some of your question, and your HN here is coolwebsearch. IMO, there's no loyal road.

 

How is it a theory if you look at your posts where security researcher had one 1 year of prep to beat Chrome's sandbox-can you possibly imagine the same situation with tightly configured Sandboxie? Nope, one entire year is just too much, plus like Safeguy said Sandboxie and Chrome are basically the same when it comes to security and protection, so why use one (Sandboxie) on top of the other (Google Chrome)?
Plus, that FleishcmannTV's post that confirmed that using Chrome under Sandboxie messes Chrome's sandbox protection.

OK, do you mean on that Google Chrome's switch so-called safe-plugins?

As far as I remember drive-by downloads are no problem for Chrome, I meant to say that Google Chrome and its sandbox are actually very strong against drive-by downloads.

Let's wait for Rmus to bypass all web-browsers and tigthly configured Sandboxie and AppGuard and DefenseWall and etc.

Well, according to Curt and by your description the game is over when you bypass Google Chrome and its sandbox, while the game is not over when you use Sandboxie for security and protection-that's how I understood it!?
But in what way the game is not over, when it comes to Sandboxie, and it's game over when it comes to Google Chrome and its sandbox-it seems to me the game is over, one way or another, either if you use Google Chrome and its sandbox for security and protection, and either if you use tightly configured Sandboxie!?

Actually, believe it or not, I'm actually satisfied with
your answers here.
Just for a record, if Google Chrome does not have access to anything including drivers, because like you said Sandboxie cannot block drivers, while there is no access in Google Chrome and its sandbox-shouldn't this be considered as more secure than Sandboxie's way (start/run restrictions)?
That's all from me, what I needed to know, there is nothing really what I need to know about Google Chrome and its sandbox and what we didn't already go through.

 

All things have been already replied. I still see many confusion in your last post, but I don't have any will to correct them, really. I hope you to stop questioning everything and instead start to search massively and thoroughly. Whatever you said, I won't reply more about this subject. If you still want to ask, ask other people. Don't misunderstand it, I didn't get mad, but literally I'm tired of and from it. Sorry for that, but I'll reply you when the subject is completely different.

 

First of all, if any mod finds this post offensive I have absolutely no problem with it being removed.

CoolWebSearch: Perfectionism in the pc security world is impossible, it will NEVER be obtained. Insisting upon perfectionism will also drive everyone crazy but the first victim will be yourself. LET GO, apply what works best for you, especially with your knowledge which is obviously well beyond the average user, and get on with it. You appear to me to be stuck in a rut, let go.

Acadia

 

The reason why I'm so persistent is not the idea I do not understand things in general, it is the fact you say everything you said about Google Chrome is merely a theory-I somehow do not believe it is all theory, especially when you posted FlesichmannTV's link where he actually proves that Sandboxie actually in real world, not in theory, messes and actually decreases and nullifies Chrome's sandbox security and protection.
Plus the facts that Safeguy wrote:
https://www.wilderssecurity.com/threads/which-is-the-most-secure-web-browser.372272/page-3
These are all well-known facts, not some man-made theories/hypotheses-this is what I could never understand from your side in the first place, that's all.

 

Just to make things clear, in my posting on the Sandboxie forum I have never said that Sandboxie decreases or even nullifies Chrome's sandbox. I have merely opened a thread because I had observed some differences regarding the SID and job objects in and outside of Sandboxie and wanted to inquire further.

Please take a look for yourself and tell me where exactly I have said that Sandboxie decreases or nullifies Chrome's security.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=18631&hilit=Chrome

I am tired of being misquoted like this.

 

What it says is that Sandboxie modifying Chrome's restrictions-how is this not as the same as I saying as SBIE nullifies and decreases some of Chrome's security and protection level, or at least actually decreases Chrome's restrictions level-basically supposedly Chrome is not any more restrictive inside SBIE as it is outside Sandboxie-that's how I understood it?
I'm not sure if Peter will allow this one your last answer here from your side, anyway, if you want, and if Peter does not allow answer, you can send me pm with answer, if Peter agrees.
BTW, I will listen to Peter's advice, and I will go back to Mozilla Firefox running sandboxed inside Sandboxie-to me Mozilla Firefox is the most trusted we-browser.

Also, FleischmannTV you specifically said the following:
"The differences are 12 job objects in default as opposed to 5 in Sandboxie. On top of that processes under Sandboxie's control run with nt-authority\anonymous as opposed to Logon SID and NULL SID.

As you can see Chromium tabs run with the job object "Active Processes = 1" by default, which means they cannot create any child processes anyway. Yet if you run it in Sandboxie, this job object does not exist and now Chromium processes can create child processes unless you apply start/run restrictions and once you have applied these restrictions you get the same as you would have gotten before without Sandboxie.

Awesome, isn't it? This is just one example of how Sandboxie disables Chromium's security features and you have to make manual adjustments only to get something back which had already been there by default."

Plus, Chrome does not have access to drivers that I mentioned eariler in the post (ClosedFilePath=C:\WINDOWS\system32\t2embed.dll
ClosedFilePath=C:\WINDOWS\system\
ClosedFilePath=C:\WINDOWS\system32\kernel32.dll
ClosedFilePath=C:\WINDOWS\system32\win32k.sys
ClosedFilePath=C:\WINDOWS\system32\drivers\
ClosedFilePath=C:\WINDOWS\system32\cmd.exe
ClosedFilePath=C:\WINDOWS\system32\notepad.exe
ClosedFilePath=C:\WINDOWS\notepad.exe
ClosedFilePath=C:\Sandbox\
ClosedFilePath=\Device\Mup\
ClosedFilePath=C:\Documents and Settings\All Users\Documents\
ClosedFilePath=%Personal%\
ClosedFilePath=!<InternetAccess>,InternetAccessDevices)

and also Chrome does not have access to dlls, exes/executions and etc., plus proven facts, not hypotheses and theories, but proven facts that Safeguy posted on 3rd page here:
https://www.wilderssecurity.com/threads/which-is-the-most-secure-web-browser.372272/page-3 (please, read Safeguy's posts #55, #66 and #71), that's all.

 

Sorry for that as who firstly quoted it was me...

I totally agree!