Is Google Chrome truly that vulnerable?

Thats not a good idea. For one, the latest version of Chrome probably doesn't work under Sandboxie 3.76. As things are now, making Chrome work with Sandboxie every time Chrome releases a new version is a challenge for Invincea. The chances of the latest Chrome version working under SBIE 3.76 is very slim. To use 3.76, you would have to use an old version of Chrome. And two, the Sandboxie version that was released last week is more secure than 3.76.

Bo

 

Yes, you're right. I totally forgot about compatibility... Is latest version of SBIE more secure on Windows XP also or just on Windows Vista and later?

 

In any version of Windows.

Bo

 

Big thank you very much for your opinion, but I'd like to still know about that win32k.sys (TrueType font exploit) that Sandboxie supposedly cannot protect unless it's patched (no matter how much restricted and configured Sandboxie4 is) and yes right now it's fully patched, for some reason Chrome can and does protect against this vulnerability/exploit before it was patched (Malwar told me that).

 

Hungry Man, what about win32k.sys exploit (which is by now patched)?
I'd like to still know about that win32k.sys (TrueType font exploit) that Sandboxie supposedly cannot protect unless it's patched (no matter how much restricted and configured Sandboxie4 is) and yes right now it's fully patched, for some reason Chrome can and does protect against this vulnerability/exploit before it was patched (Malwar told me that).

 

My answer is the same: not all vulnabilities relate to the software you are using on your OS, not all vulnabilities are exploits, there is only a small chance to encounter an exploit, infection risk can be reduced by safe-hex practice.

On XP I would use DefenseWall or Sandboxie, DefenseWall when you want seamless protection, Sandboxie when you want protection and auto-flush the toilet after visiting the darker corners of the web.

On win7 or higher I would install a freebie (like EMET for Office aps and MBAE for browsers) specially developed to tackle exploits. When you have a SBIE lifetime license and are pleased with it, keep on using it, since SBIE has excellent track record.

Point is that few Wilders members run exploit kits to determine what is best, so we are talking opinions here not facts. Unless anti-exploit is a complete marketing bogus, I would assume a special designed anti-exploit would be more effective as a general purpose application sandbox like SBIE. But this is just a guestimate, so enjoy your setup.

 

Right on the money

@ coolweb,

it is possible to run a Chrome-based browser (Chromium, because you are worried about privacy) with a significantly elevated level of security but it would mean some considerable spade work on your part to do so, as well as the willingness to accept a different OS than Windows (A Vitualbox setup within Windows might be possible, meaning you only use linux for Internet browsing), although I don't want to ramble on trying to push this on to you. Let's just say it's tough to beat the sandboxing linux provides for Chrome/Chromium browser.

Our friend Hungry Man provides a nice write up on it about half ways down the page:

-http://www.insanitybit.com/tag/chrome/

All that said, if you stick with Windows, no problem there. you can run Chrome securely enough in that environment as well, especially if you are willing to embrace a scripting control extension. Don't overlook what Windows_Security states above. TyRidian's suggestions are very good too.

 

... This is not the definition of "exploit" I am familiar with.

Anything that executes arbitrary code in a program's memory space falls under the exploit umbrella. That includes really limited ones that just invoke a binary payload. If something can make your browser run an unwanted EXE, it probably wouldn't take much tweaking to record your keystrokes within the browser window, etc.

Re rarity, I think the numerous ITW exploit kits would disagree with you. Last I looked on the Malware Domain List, over half of the attack sites on any given day were running stuff like Blackhole.

It's not just "dark corners" though. Watering hole attacks through embedded ads have been pretty common for a while.

This may be the case. However

[soapbox]

At the moment I'm very skeptical of anti-exploit software on Windows, other than EMET. I mean, this is memory management stuff. How do you improve the safety of Windows memory management - patch core kernel components in RAM during boot, or something? Intercept memory allocation syscalls? How does a driver or system service fix inadequacies in the lowest level parts of the NT kernel?

I have no idea how it works, and the vendors have a vested interest in keeping it that way (trade secrets etc.) And while I more or less trust the vendors not to be malicious or fraudulent, not even knowing the conceptual basis of the software is a huge issue for me. If X piece of software is supposed to make my computer more reliable, the last thing I want to be is a black box that works by unknown hidden mechanisms. Transparency is IMO a big part of reliability. You want to at least know the conceptual strengths and weaknesses of the software you're using.

And this anti-exploit stuff, well... it's a bunch of highly proprietary secret sauce extensions, to an OS whose internal mechanisms are themselves proprietary. Maybe it works, but trusting a completely unknown mechanism to enhance my OS's security doesn't feel right at all.

[/soapbox]

 

I noticed people on this thread are mentioning that chrome uses windows built in security measure to toughen the browser..my question is how does chrome security fare on a linux system as this would seem to imply that chrome is more secure on a windows system.

 

The sandbox on Linux is more secure, probably by a wide margin with recent kernels. The renderer runs under
- An empty chroot/setuid sandbox (no filesystem or VFS access)
- Seccomp-BPF filtering (only an approved subset of syscalls are allowed)
- Separate PID namespaces and Yama LSM restrictions (can't communicate with external processes)
- Separate network namespaces (not sure where this fits in, maybe stopping man-in-the-browser attacks?)

Seccomp doesn't work on older distros like Debian Stable (needs a newer kernel), but it's probably the most powerful of those, because it alone can block direct attacks on the kernel. I don't believe Windows has anything like that at the moment.

Windows sandbox is described here:

http://dev.chromium.org/developers/design-documents/sandbox

Pretty strong restrictions, especially on Vista and later, but no seccomp.

 

Refered to this in my post before " . . . does not create a predictable and exploitable intrusion".

Correct called that a show stopper (but you still have to check at the details of a specific vulnability not all exe vulnabilities lead to capturing of info or elevating of rights), problably my bad english

For reasons of flushing traces (other users of that PC don't see what they have browsed) not for protection (DW is as good as SBIE in protection), problably my bad english also.

Yes I said opinons not facts, is my Dunglish so bad?

 

Your English is quite good. Sorry about the soapbox thing; I know you were talking opinions, I was thinking more of the marketing push for anti-exploit software. (I like the idea of less intrusive security software, but have deep misgivings about anything using such unclear methods.) That was not a response specifically to you.

Re "predictable and exploitable intrusion," I see what you're saying. "Predictable and exploitable intrusion" is not at all uncommon though, it's just that most of the time the consequences of the intrusion can easily be blocked.

 

Okay thanks for the explanation, that is why I made the marketing bogus restriction/caveat.

 

OK, big thanks to all, but I have one simple question: can is Google Chrome the most secure browser as it is claimed or this is completely false?

And btw, Windows_Security I will listen to your advice, thank goodness I do have lifetime license from Sandboxie, and I do have a license from AppGuard and I will stick with these 2 for a very long time, because I'm so pleased with them.

 

WS, what about that attack surface that Hungry Man was talking about?
How does affect Sandboxie4 for example?
He was talking about that running sandboxed Chrome will only increase attack surface whatever that means.
Sure, Hungry Man said that Chrome has Untrusted, has no read/write access to the entire file system, so how tight is that?

Sandboxie as far as I know does read/write access to the file system but it can be fully configured to completely disable read/write access to entire Windows file system?

 

Attack surface
Well attack surface means more code, more chances to make a coding error, hence more vulnabilities and exploit opportunities. Now it becomes complex: adding extra code increases the chances of a vulnability, but adding more code also reduces the chances of a vulnability to create a predictable flow of events. In theory Hungryman is right, but it is a bit far fetched to state theory as fact, because it is hard to tell what weighs in more.

Chrome Sandbox
Untrusted with a job object allowing only one process on a alternate desktop is a pretty tight security boundery. The Chrome PDF plug-in has limited functionality (so less code to be breached). With PPAPI flash the API is smaller than NPAPI flash (smaller door and hallway, less bad guys comming through) so it even tightens it further up. Javascript engine uses hidden classes to reduce the effects of breaches also (okay you are out of the jail, but find yourself in a dark dungeon with no clue what to break next)

SBIE file control
When a malware is able to break out of the Chrome sandbox, the underlaying OS is probably breached, so the mechanisms SBIE uses to block access to entire file system could also be breached, so that is also a theoretical SBIE advantage. See explanation at attack surface. It is hard to predict the outcome (better or worse), but my guess is that an additional layer (like SBIE) makes it harder to find a (combination of) bugs which is workable and predictable enough to justify the cost for developing such an exploit kit.

 

I don't know about increased attack surface, but I believe that current SBIE versions use Windows integrity levels to do the heavy lifting; so with Chrome already using an even lower integrity level it would be a bit redundant.

OTOH, Chrome does not sandbox all plugins. PDF readers, Java, etc. that are not contained by the Chrome sandbox, could be contained by SBIE. I would say it's better to disable such plugins in the first place, but that's not always possible, so...

As far as Chrome being the most secure browser, I would bet it is, at least out of the box... But out of the box is not good enough for me. I would still turn off Javascript and plugins on untrusted pages.

 

Yep, but I don't use HTTP switchboard or Scriptdefender, just GPO hardening with click to play and block javascript except (allowing) from COM, ORG and NL and uBlock for ads.

I have played with anti-script tools, but found it to much of a hassle. Also experimented with SecuriSiteCheck in combination with Quick JavaSwitcher, but found it needed to much micro management.

 

I run Linux with a custom kernel, HTTPSP, firewall, and apparmor.

Which statements specifically are you referring to?

There are no privacy issues with Chrome that I am aware of. Anyone with want of a more private browser can just go to the privacy settings and disable some features that send usually non-identifying data to Google.

I have met and know multiple Chrome developers. I know their stance on privacy. I would trust them over most companies.

I've never done an in depth analysis of Sandboxie, especially not hte latest versions, which utilize a new method for sandboxing. As far as I can tell it offers little to Chrome users, but can be powerful for non-chrome users. They work similarly.

Anyone who thinks that doesn't realize how these vulnerabilities work.

edit: @GJ,

Chrome's PPAPI plugins should be sandboxed. That should include the PDF reader et al.

 

I was referring to posts like this what Malwar, Boerenkoo and Fleischmann told:
https://www.wilderssecurity.com/threads/is-google-chrome-truly-that-vulnerable.365739/#post-2400799
What do you think, Hungry Man?

Also on AppGuard sub-forum Boerenkoo wrote this about exploits:
https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-83#post-2400428
What do you think, Hungry Man?

Also, TyRidian wrote this:
"Chrome Sandbox = Run's in a restricted environment, Prevents arbitrary code that may cause damage to the system, Helps prevent exploits from reading or writing any information from the system (Sounds perfect, but not always the case)"-now, what does this exactly mean, that it's not always the case?
What does this mean? I thought this is always the case with Chrome in 100% of all cases.

Also, I'm still trying to ask you if this win32k.sys truetype exploit was truly able to break out from Sandboxie, but was protected by Chrome (before it was patched), like Malwar said?
How is this possible that this win32k.sys was able to break out from SBIE those days (and still can't protect against win32k.sys exploit, but it's a non-issue anymore because it was patched), and yet Chrome after the bug in itself was fixed, was able to protect against it?
And of course, is this true or false?
I think you're the one who might know this, also Malwar was the first one who recommended me how to configure SBIE, but also told about this win32k.sys exploit before it was patched?

Borenkoo also specifically wrote this:
"I'm not sure if this is completely true, so others can feel free to correct me:
The win32k.sys is a kernel exploit. ("The kernel is a program that constitutes the central core of a computer operating system. It has complete control over everything that occurs in the system.")
The win32k.sys exploit exploited a vulnerability in the TrueType font and some guy at Microsoft apparently thought it was a good idea to do the TrueType stuff in the kernel.
Normally, if your browser or plugins get exploited, the exploit usually drops a malicious payload on the disk and executes it, so it needs start/run permissions.(There are also memory-only exploits that stay in the memory of the exploited application so they are harder to detect, but they are also harder to pull of and don't survive reboot, so they are less common.)
In the case of the TrueType exploit, the font is used by the browser so if the exploit is successful, it can move from the browser directly to the kernel without hitting the disk and needing start/run permissions. Once the attacker controls the kernel, he/she controls everything so can easily bypass security software.

I don't know if other kernel exploits also have a direct exploit path like this once, but since the common consensus on this forum is that security sofware cannot protect from them, makes me believe other kernel exploits don't have to hit the disk as well."

So if this all true, than how could Chrome protect against this win32k.sys exploit when SBIE could not and still can't (this is the impression that I had after Curt from Invincea answered on SBIE forums) and never will because start/run restrictions and internet access restrictions do not apply in this win32k.sys kernel-level exploit.

Here is Curt's response:
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=19163

"I will clarify a few things. kernel32.dll is always called kernel32.dll -- even in 64 bit Windows. It is always loaded into every Windows app. win32k.sys is a Windows kernel driver. It contains the kernel side of the Windows session manager (you can look these up in wikipedia for more information). Your ClosedFilePath settings in sandboxie.ini have no effect. You can't block a driver with ClosedFilePath.

Kernel exploits, Chrome, Sandboxie, etc. have been discussed in many forums. You can start with this thread:
Here are reactions to Bromium labs tests:
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=18098"

What do you think, Hungry Man?

 

One more thing you wrote:
"Chrome Sandbox = Run's in a restricted environment, Prevents arbitrary code that may cause damage to the system, Helps prevent exploits from reading or writing any information from the system (Sounds perfect, but not always the case)"-now, what does this exactly mean, that it's not always the case?
What does this mean? I thought this is always the case with Chrome in 100% of all cases.

 

Nothing works 100% of the time. Even if your sandboxing mechanism is formally verified, there can be implementation bugs. Even if you whole kernel is mathematically proven solid, and written in a demonstrably safe language, you can have
- hardware and firmware bugs
- bugs in the language compiler
- obscure errors in your calculations

The Chrome sandbox is relatively very good, but it's working with buggy OS kernels that hold to archaic standards. And both Chrome and the OSes it runs on are written mostly in C and C++. Programming in those languages is like doing ballet on thin ice while wearing stiletto heels.

If someone claims their sandbox is 100% effective, there is probably some very small print underneath with a lot of disclaimers.

@Hungry Man: the Chrome PDF reader is sandboxed, but other PDF reader plugins (Foxit, etc.) wouldn't be; those are the ones I was referring to.

 

In some cases, in the event of the attacker having a sandbox escape vulnerability, it can not protect the user. Those vulnerabilities can be expensive, though it really relies on you using a more modern OS, as kernel security waws not a priority in OS's like XP.

I don't know the details of this. Chrome renderer's have some restrictions on how they interact with the kernel on Windows, so that could be responsible. In the case of truetype, I think most browsers at this point have a lot of protections against how they sanitize or block text in order to prevent kernel exploitation.

While kernel32 is loaded into every process, Google is working on removing it from the renderer - I assume by creating imports and then having the broker unload it. This is available on the canary channel, I believe. That would mean the Chrome renderer would be unable to make many system calls, thus reducing kernel attack surface. This is there attempt to get to seccomp-like sandboxing on Windows, though it's a total hack and I don't know if it will ever see stable.

 

"OTS r95 will reject the font. This means Chrome won't load the font at all and fall back fonts will be used." http://code.google.com/p/chromium/issues/detail?id=146254

 

Yeah, I figured. Firefox and other browsers should have similar behavior. That does not mean it is invulnerable to such attacks, but yes, they do defend against these things. Sandboxie, being a generic sandbox, is not capable of making rules like that.