Sandboxie technical tests and other technical topics discussion thread

I understand.
Actually, whether sandboxing Chrome is worth doing or not depends on how they use browser & SBIE, and what is their purpose.
No one will say sandboxing Chrome is meaningless when it comes to privacy because even Incognite mode is not perfect.
Also as you suggested, there are/can be many many ways to use SBIE and to use Chrome, and each user's skill & knowledge also vary.
I believe those who know malware & intrusion well don't need sandboxing Chrome for security purpose since they know how to avoid malware and never been click-happy.

Chrome only blocks exploit (I now don't count Chrome's other protection as it's another sroty), and in this regard Chrome is very strong, SBIE wouldn't add much protection.
However, SBIE don't only block exploit but also care about user execution.

So IMO it is to some extent comparing apple & orange, though they have duplication.

Well, Google should use better word, but it actually controls whether you sandbox plugins or not (or want to get prompt).

 

Glad you mentioned this, and in combination with Emet, it seems to me this would greatly reduce risks of combining Chrome and Sandboxie (I think it was 4.08 that introduced ASLR support?)

 

Well, SBIE4 is at least as strong as Google Chrome when it comes protection against exploits.

 

I don't think so.
SBIE is designed to work with lots of applications, so it can't apply strict rule set by default.
Yes, you can configure SBIE through restriction(network & start/run) & access control , but Chrome's renderer process already have no access to folder/registry, can't make network connection, and can't spawn another process.
SBIE conducts not only security related tasks, but as it have to maintain compatibility with lots of apps while keeping security, it performs many tasks. SBIE converts global hook into app-specific hook. It redirects file creation to virtual environment. To do those it inserts dll into monitored application. And there're some IPC exception made by compatibility settings.
Such complexity can make possible attack surface.
But even if it matters, it would be in a situation like APT―advanced persistent threat.

As you said if we talk about usual exploit which we come across, then Chrome & SBIE are equally secure as long as SBIE is properly configured.
Also in usual targeted attack, SBIE will be able to protect corporate user well (I know Invincia provides more full-fledged product for corporate user.)
But if we talk about certain kind of targeted attack, it's completely different story.
In such a situation, every security product can be bypassed.

I saw your question about Duqu, but what you missed is Duqu is targeted malware.
So actually a fact 'Product X can stop Duqu' doesn't make sense.
That just means victims Duqu targeted didn't have that product.
If they used that product, most likely it was bypassed.
IOW, targeted malware is specially crafted malware to bypass that target and not for common attack, though usually those malware somehow are leaked and spreads ITW.

Of course the fact every security software can be bypassed doesn't mean corporate user don't need to use them.
What matters is how to make intrusion more hard and raise costs & effort for attacker to penetrate.

Though actually comparing sandboxied browser (it must be Chrome w/out sandbox. Otherwise, there's no fair comparison) alone with Chrome alone for robustness against sophisticated exploit is nonsense, if still do, I think Chrome is harder as many security experts are tying to find vulnerability in Chrome and simply Chrome doesn't need to perform complex tasks which I mentioned above.

But in actual case, no company should rely on single product to protect them.
Such comparison is like comparing a bulletproof jacket with helmet for just an hardnesssolidity in physics lab.

 

Hi Yuki, I wonder, if someone gets hit by Cryptolocker while opening an infected webmail attachment, would this user be as safe running Chrome on its own as he woukld be if he was running the browser under Sandboxie?

The only attachment that I open while browsing are PDF, always sandboxed and out of the browser. I dont install the plugin. I think you as I open all attachments sandboxeed. But most people usually open attachments as soon as they see they got one. Sandboxie protects against Cryptolocker. So, would this people be more secure against Cryptolocker if they were running Chrome under SBIE or not?

Bo

 

bo, I'm aware of that.
So I intentionally said 'exploit' in previous post, not malware, except mention about Duqu.
In that post I only focused initial exploit, but actually that aspects are also covered in last paragraph.

BTW I open PDF within Chrome so it is protected by Chrome's own sandbox.
As to other document from untrusted source, maybe I'm too paranoid so using OfficeMalScanner.
But I agree, most user just open them immediately so it's huge advantage of SBIE.
But it shouldn't be table where we compare robustness for exploit, though as I said it's actually almost meaningless.

 

Maybe my words are still not clear, or confusing.
Pardon me as English is not mother tongue.
I had to say, exploit against Chrome/SBIE itself.
Exploit through infected document is not a scope of post#105.
Yes, it's not real life situation what I illustrated in #105, this is why I said nonsense/meaningless.

 

Yuki, another benefit that I can think of running Chrome under Sandboxie is the ability that Sandboxie gives users to block programs running in the sandbox from having access to your personal files and folders. I mean, I know malware looks in the My Documents folder, I think that's pretty standard for a lot of malware. I pretty much keep nothing thats personal and important in My Documents folder but I block access to it in Sandbox settings. And I block all personal files and folders where I keep sensitive files from being accessed by programs that run in the sandbox.

One more benefit. You know how webpages where people download installers from have links that fools and confuse users and then later realize that they clicked the wrong link and ended up installing something else, in some cases, malware or adware. That aint gonna happen to Chrome users running the browser under Sandboxie. Even when the user is using an unrestricted sandbox and no Drop Rights, the installation, if it succeeds, its gone after deleting the sandbox.

Bo

 

There are many ways to use SBIE. I've personally yet to see why I should sandbox Chrome in real-life scenarios (if your system is clean). I run suspicious downloads sandboxed.

As for regular people, what if they want to install software? SBIE won't protect them in that case, unless someone more experienced manage all installations.

 

I treat all downloads the same way. I dont care what it is or where I got it from. If its in my computer, it runs sandboxed until the day it gets deleted. There are rare exceptions but thats pretty much what I do. The only time that I run a download out of the sandbox is when I am going to install something new in the computer. But this is extremely rare for me. I pretty much have my computers all set and dont install anything new. Most people are not like that but for someone like myself, it works great to use SBIE the way I do.

Bo

 

Well, I trust VirusTotal enough, and so far so good. Also got AX64 just in case. The whitelisting approach is more secure, but too inconvenient for me.

 

HI J L. White listing programs in Start Run settings can be inconvenient for free SBIE users but Sandboxie allows free version users to create and use more than one sandbox. Most free version users dont take advantage of this benefit. If they did, they would create dedicated sandboxes. You can't use more than one sandbox at a time but it shouldn't be too hard to get used to using different sandboxes for what you are doing once you get in the groove of using more than one sandbox.

The paid version makes things more convenient and less thinking is required to get your programs and files running sandboxed. Pretty much all my files and programs run sandboxed automatically, the only question is in wich sandbox the file its going to run. For me, that depends on where the file is at in my PC. I do it like that by combining the paid version features (Forced programs and Forced folders) and using a sandboxed Windows Explorer. I do things automatically, its so easy.

Bo

 

My bad, I didn't mean to start this discussion all over again, and I actually agree with you. But I think my "virtualization only" idea will probably not be popular with Invincea. What I'm asking for is already done by apps like Evalaze and Cameyo, but without the security that SBIE provides.

Like it has already been said, SBIE v4 is most likely just as secure, or perhaps even more secure than v3.

 

http://youtu.be/aMtyGNviiRY

 

Sandboxie, Cryptolocker and Sandbox settings that maximize protection.
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=16878&sid=93c7d38bd80221dd3a8fb05fc7ed147c

Bo

 

This is a huge element of the mix for me - in a lot of ways, my data is far more valuable to me than my system, and I think the invisible exfiltration threats are increasing. It's just too easy for exploits with no ability to escalate or change things to read a file system - after all, it's even less than CryptoWall. They can run in memory, have no admin privileges, and "only" see what the user sees. This applies whether they are sandboxed or not.

I see no reason at all why any system should allow stuff like browsers unfettered access to my real data, and would like some usable MAC like AppGuard on Linux but really usable.

Right now, Sandboxie is the only mechanism I have for achieving anything of that sort, other than running many things in a VM (which I also do).

 

I think I understand now the advantage of Chrome over SBiE4, however I have one question about Duqu malware:
I read on Sandboxie forum, that when you block t2embed.dll, it will block also Duqu malware?
How exactly, since we're talking about kernel-level threat here?

Also, if I block the following:
ClosedFilePath=C:\WINDOWS\system32\kernel32.dll (It could say kernel64.dll instead of kernel32.dll depending on the operating system 32-bit or 64-bit)
ClosedFilePath=C:\WINDOWS\system32\t2embed.dll
ClosedFilePath=C:\WINDOWS\system32\win32k.sys

But like Curt said SBIE cannot block win32k.sys and kernel32.dll, what about the rest of .dlls?
Also, how effective would be blocking t2embed.dll against Duqu malware?
But if Duqu malware is especially targeted malware, would blocking t2embed.dll have any effect at all?
Malwarebytes anti-exploit at least blocks the Duqu payload.

 

Well, Yuki said that Chrome does not have any access to your data, actually it does not have access already have no access to folder/registry, can't make network connection, and can't spawn another process read his post above between Sandboxie and Chrome.
However, there are 2 other software programs that match SBIE on everything mentioned on Windows: AppGuard and DefenseWall, however DefenseWall does not have 64-bit support while AppGuard has 64-bit support.

 

Thanks for the info, I actually meant AppArmor on Linux, I think that's the kind of MAC I'm after but simpler! It's my view that this stuff should be a part of the kernel, not left to 3rd party apps to implement.

I wasn't aware the the Chrome child processes restricted that file and registry access etc, that's useful.

 

Bo, I know you're always kind to people and you're one of the master of the SBIE even though you don't see yourself as such.
I myself learned a lot from you, as I've read your posts in SBIE forum, malwaretips, and here wilders.
Now I'm no more beginner, really thanks to you.
I'm enjoining full capability of SBIE paid.
So please understand what I actually trying, despite my language limitation.
I said in #101

In post #104, I intentinally cut all aspects except robustness to penetration.
I know well that all attack are always in a context, so just extract certain element and compare it is almost meaningless―however sometimes it can bring some light, just like Chemical experiment where they use pure substance which rarely exist in real world.

Who says helmet is more important than bulletproofjacket because it is phｙsically harder?
What matters is how to protect yourself from bullet, of course harder is better but there're many things which should be taken into account.

#104 is only for response to CWS' #103, no more or no less than that.

However, I still appriciate your comment with some sentiment or what, I don't know correct word, but because what I first learned how to restrict SBIE is from your old post in a forum.

BTW, I forgot to mention one BIG benefit to sandbox Chrome by SBIE, and I'm sure CWS will have interest.
Chrome doesn't―rather, can't―restrict access to FAT32 format filesystem. And most USB thumb drive is FAT32 by default for compatibility.
So if you have had USB plugged into your machine while are browsing, and if exploit happen, yes Chrome will contain it but if it try to infect USB with say, USB worm then Chrome doesn't block it.
You can format USB drive with NTFS to avoid this, but remember if you did that Mac OS or Linux can't recognize that USB correctly.

 

Blocking t2embed.dll block TrueType font vulnerability, and that vulnerability is used to infect victim by Duqu.
So actually it does not block Duqu itself, but a way attacker used to infect victim.
Then, if attacker know victim somehow always blocking t2embed.dll, they would trid another way.
Remember in that time, the vulnerability was UNKNOWN. How can you block unknown exploit by restriction rule? Do you know what component will be targeted by next kernel exploit?
So this is APT, especially really sophisticated one. It is said some national force keeps stock of 0day exploits.
But also remember such attack costs much $. It is really unlikely such attacker targets us.

MBAE blocks that payload is great, but it doesn't make sense in real sophisticated APT.
In Duqu case, attacker already had kernel priviledge, so if they want they can uninstall MBAE.

And BTW I'm not necessarily talking about kernel-level threat in past posts, though yes TTF exploit is kernel-level threat.

I think you can block most dlls on your disk if you set proper access rule, but think you can't block ntdll.dll, kernel32.dll, and kernelbase.dll.
I don't know about how sandbox behave against remote dll injection.

Also, I didn't said Chrome does not have any access to your data, if so how can you download files?
What I said is Chrome's renderer process is such, so deBoetie is right since he says child process.

Chrome has 2 kind of process, renderer & broker.
Broker is a kind of supervisor, so relation btwn broker & render is like teacher & lame but diligent student.
If renderer need certain resourse, it asks broker "Can you give me a favor? I need..."
Then broker checks whether is is permitted by regulation and if it's okay then he access it on behalf of renderer.
So while render can't directly access any resource, he can concentrate on what he should do i.e. rendering.

 

I am glad to read that, Yuki.

To me, its kind of disappointing when I see people perceiving Sandboxie as if all it was is a browser in a sandbox, in my personal opinion, disregarding and not doing all that can be done with SBIE is exactly the opposite of taking full advantage of Sandboxies capabilities. Even with the free version, users can sandbox all their browsers, USB drives, CD and DVD drives, download folder, Windows explorer, run any file or program in their computer sandboxed, use more than one sandbox, use dedicated sandboxes, etc, the options to do all that are available but most people don't take advantage of all that SBIE offers.

Bo

 

Here is the one thing about exploits: SBIE4 does block exploits, I still fail to see why do you consider Chrome better in this area, if Sandboxie4 also contains exploits, Curt recently confirmed to me that SBIE4 does actually protect against file-less Angel exploit kit (yes, the memory thing).

There is also one thing everyone should be aware of: I tried to surf with my Chrome and I have hitman pro for scanning, for some reason, whenever I surf either Google Chrome, Mozilla Firefox or Internet Explorer, ask.com installs itself and I have to clean it with HitmanPro-what the heck is ask.com?
HitmanPro recognizes it as malware.
However, whenever I surf all of the mentioned browsers under the supervision of Sandboxie 4.14, ask.com can never install itself in the first place!
So, yes, I will definitely keep my Sandboxie4 after a long thinking, I simply trust it because of both security and privacy and because of this bad experience.

 

It doesn't matter if you block all dlls and every program and application than Duqu can't really do anything to infect in the first place, but if some of the crucial dlls that cannot be blocked are infected (the ones you mentioned: ntdll.dll, kernel32.dll, and kernelbase.dll) than there is nothing you can do about it, except delete sandbox in the first place.