The Chrome in the wild exploits inventory

Exactly speaking in current Chrome, plugins are either can't run at all or sandboxed. Sure, not all plugins can be sandboxed but anyway if any plugin tried to access your PC, Chrome prompts against it by defualt. Setting I mentioned is "Unsandboxed Plugin Access" which suppresses the prompt, but I was bit lazy to search for correct English translation of that.

[EDIT]Yup, unless whitelisted.

About Java sandbox, I agree. It's sandbox just make securing it harder.

 

This is merely a theory from your side ( I read your post in previous thread on page 3, but this only you, I haven't seen this confirmed by Hungryman or or real world tests or tested at all), and with Chrome and Sandboxie there is too much with words "might or might not" (WIndows security stated "might or might nowt" about if Sandboxie could protect from remote code executions/exploits that are able to bypass Chrome, could be and should be, but no definitive proof with the real testing, since there are were no real tests about security and protection at all.
It doesn't have anything with extreme fanboyism because I'm not fanboy of anything, it's just how much indefinite and unanswered and untested things and issues with Chrome and Sandboxie there are, since none actually knows what's better and more secure, for me right now the best option is Fifefox and Internet Explorer running under Sandboxie, and that's what I use.

 

LOL, you are kidding me, are you still trapped in the war between Chrome vs Sandboxie? Let it go.

 

How did this become another SBIE thread?!

Anyway, re Chrome vulnerabilities, I think right now I'm more concerned about holes in the smaller supporting libraries and programs. When was the last time NetworkManager got a security audit, for instance? Or dhcpcd? I can't speak for Windows, but the Linux userspace is full of tiny little C programs that perform important networking tasks from privileged user accounts. To me this sounds like a problem waiting to happen.

I mean, everyone thought OpenSSL was safe, to the point that it was highly recommended by a book I have on embedded Linux systems. The bash shell, curl, and wget have all had major unexpected holes. So my guess is, the next big-name vulnerability will be in some little library or utility that nobody thought was important.

... That's for Linux though. Not sure about Windows. However, looking at the history of MS security bulletins, my suspicion is that Chrome is one of the least vulnerable applications you might find on a Windows desktop.

 

I did let it go.

 

It did not become another SBIE thread at all, but it did become more to like Chrome thread, no more SBIE posts.

 

The whole point of this thread is about Chrome, not SBIE.

 

Things were getting lost in translation as it seemed you were writing Java is sandboxed within Chrome and the "unsandboxed" switch forces the sandbox when it's the opposite.

No matter though as I believe I now grasp your posts, and we are close to being on the same page.

Once again, I was showing you what exploits exist ITW and where I am actually faulting Oracle. So if we were talking Firefox exploits you could consistently name Flash. But you could also name mitigation: C2P, the fact you rolled a suggested Flash update, or just don't install non-native plugins.

The updated Chrome NPAPI/PPAPI c2p mitigation likewise doesn't change the fact that current exploit kits STILL use unsandboxed processes to exploit Chrome especially considering it is not forced nor permanent. "It is what it is." If you/chrome prevent it or you don't even have Java plugin installed, then clearly the EKs I mentioned wont work.

When Chrome fully deprecates Java/NPAPI, the current EKs will only apply to outdated Chrome/Chromium/portable versions until new exploits surface and are implemented. It is likely, they will update the once successful exploit pages to forward people who are fully mitigated to a trojan/social engineering like they have in the past.

Cheers.

 

You know, I always hate when when people and experts say every time that Chrome's own built-in sandbox was bypassed, it wasn't Chrome's sandbox itself that gets bypassed, what gets bypassed are vulnerable parts outside the protection of Chrome's own built-in sandbox-extensions, plugins, java, flash players and similar.
CVEs and RCEs (remote code executions) and all other bypasses confirm this.

 

You said:
Sandboxie's sandbox is even less restrictive by design (to ensure compatibility with as many apps as possible).

Let's suppose this is not the case with Sandboxie, and it does not have to be compatible with any app at all, would it be more restrictive and more secure, and that is a million dollar question...

 

@Kees,

hopefully you can go into some detail about this. A typical drive-by download attack in most cases redirects the victim to another different website that's hosting the exploit. The website that's trusted, if hacked, will most likely have a malicious iframe that triggers the redirect. Even if one has whitelisted the entire active content types of the website, who's to say the website being redirected to, that's hosting the exploit, has been whitelisted? If it hasn't been whitelisted, the attack should fail at this point. Therefore, script blocking has done its job.

If I'm wrong that's okay, but please explain why.

 

Yes in most cases, for a typical drive-by attack, that is exactly my point.

Assume for argument's sake that 80% of intrusion are drive-by's downloads. Let's for argument's sake assume that 80% of those drive-by's do not directly download code but first redirect to an attacker controlled website. This implies that for 64% of the cases (80% x 80%) you are protected by a script blocker.

As is often shown by the tests of AV-comparatives MSE "only" protects against 60 to 65 percent of the malware samples. Most of the members of this security forum think that percentage is joke. Now why do you consider script blocking a serious and proven protection when it protects at best against 60-65 percent of the cases.

I am not telling you are wrong in your reasoning, I am just red nosing some favorite topics here on Wilders, by discussing it from a different angle.

 

Thanks kees, well explained. Assuming your numbers are correct, that's admittedly not a great level of security. One thing to take into consideration, however, is the way the script blocker is setup, not to mention other layers that may come into play.

1. Script blocker set for above average granularity
2. HTTPS Everywhere
3. Chromium running in Linux' sandbox
4. Chromium further sandboxed with something like firejail
5. PPAPI flashplugin (not Adobe's).
6. No Java plugin

Even if the script blocker is providing only 64% security (I would contend in my case it's higher than that), when you factor in the other security measures, you're very likely looking at much closer to at least high 90's%. Also one must consider the near zero resources used by script blocking as opposed to AV. Even if you ran the above on Windows Vista or higher (even minus the additional sandbox), you're looking at an extremely robust setup.

We would also assume the user has kept up to date on the browser and extensions/plugins, O/S, etc...

 

The question was not pointed at me but will answer anyway. We or at least I will think it is a joke as a protection mechanism if it is your only line of defense. Coupled with other software you can get quite nice protection.

Seatbelts at best prevent 50% of deaths in car crashes. Would you consider it a serious and proven kind of protection ?

 

@wat0114 & @phalanaxus

I could not find a exploit in the Wild list for Chrome (at least the last five years not). So it is safe to assume Chrome itself offers 99.99% protection. So why bother adding a protection which offers 2/3 of that level. Security is about the weakest chain.

 

I can agree with 1st part not needing to add another layer for chrome in this regard. But I don't think security is about the weakest chain, in this example if something goes past your script blocker chrome won't simply decide and let it do whatever it wants.

 

You make a good point again, kees. The exploit kits will fingerprint not only the browser but also plugins and extensions, the O/S, plus lots of Adobe and Microsoft applications I guess it makes running Linux practically a non-factor, then.

 

In theory, exploiting Flash on Linux should be possible, just as long as you can get RW access to the user space memory.

 

Makes sense. I'm running the out of process (PPAPI) flash, though, so I'd think it's far less of a concern than Adobe's flash plugin.

EDIT

kees makes compelling arguments in this thread and another one about script control so, although I can't let go of script control, I've reduced the extension's aggressiveness as illustrated here a few days ago.

 

PPAPI flash plugin is still Adobe's, compiled and signed by Adobe and bit-for-bit identical to the PPAPI flash that ships built into Chrome. Unless you are referring to NPAPI in comparison when you mention as Adobe's flash plugin.

Your setup is fantastic, by the way. Zero worries with a tight setup like that and you've got the granular control to fit your needs. It's been some time since
i last used Linux exclusively. Just in my router now with OpenWrt.

 

You are right, it is Adobe's, far more secure than the NPAPI plugin which I should have referred to. Hungry Man has a nice writeup on it in his Blog page. BTW, thanks for the kind words on my setup

 

Windows Security, I don't think that you and Yuki even tried to understand what I was trying to say: I posted this to you Windows Security is because of another post in another thread, where you actually posted that running Chrome under Sandboxie (with ultra-tight restrictions) might or might not protect against exploits that are able to break through Chrome's sandbox (again, not plugins and extensions, but pure Chrome's sandbox itself (without plugins and without extensions) which is much harder/very nearly impossible to exploit, unless there are kernel level exploits).
Personally, when you say might or might not protect against exploits it is more like an half-answer, i don't know why it can't be said, yes it will protected, no, it will not protected, without ifs and buts, without 50:50 chances (I hate statistics, because they never show what's truly behind the surface)

 

Tho I admit I might not get all your meaning correctly and can't always convey what I mean thanks to my English limitation, I don't think I said/meant java is sandboxed by Chrome and don't think you specifically focused on java in #7 but may be wrong. I talked about plugins in general and when unsandboxed plugins can't launch itself (exactly speaking, make prompt to launch in default config), why I care about them? I already said same thing here but wanted to avoid go into too little details, just like you firstly avoided detailed comment in this thread.

Also as to unsandbox plugin access setting, it's not the opposite. While you can disable sandbox from this setting, you can also suppress the prompt so that no unsandboxed plugin can run i.e. force sandbox.

The problem is, as I mentioned, common user can easily allow unsandboxed access by just one click, this is why these measure are not good enough to protect them, same as MS Office's protected mode.

 

To give "evidence" you want, one have to be able to penetrate Chrome but that is extremely hard and there's not many PoC available (except kernel exploit) so how can we give that "evidence"? Possibly some very knowledgeable person can give, at least not me.
For people who can understand basics (sorry but obviously you're not, as I find many misunderstanding in your last several comments about the matter in SBIE thread) and logic, known facts are enough to conclude what safeguy said. But do not turn this thread into SBIEing Chrome thread just for your curiosity. Most if not all of us are not much interested in your obsessive question.

 

That's fair answer.