Is Google Chrome truly that vulnerable?

Take a look at what DIGITOL quoted from the Chromium webpage below and posted in red at the Sandboxie forum. Look under "Sandbox windows architecture." I think, what it says there is the reason he arrived at the conclusion that you don't agree with.
http://www.chromium.org/developers/design-documents/sandbox
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=11788#p74053

Bo

 

Yes, indeed, I forgot to mention this to GJ and to HM.

 

@bo elam,
@CoolWebSearch

Thanks, I see that on the Chromium page.

This is a really weird choice of terminology, because the mechanisms for creating the sandbox are based on system calls. (CreateRestrictedToken is a Win32 API function that relies on native API functions provided by the kernel.) It's only "userspace" in that no modification to the OS, or admin privileges, are required to invoke it.

(Note BTW that there do exist restriction mechanisms based more purely on userspace libraries. SRP is one such mechanism - and its userspace implementation is why it's considered inferior to AppLocker.)

Re Sandboxie vs. internal application sandboxes, I'm just going to point to this again:

https://www.wilderssecurity.com/threads/application-sandboxes-a-pen-testers-perspective.350960/

where we already discussed this extensively. Things may have changed a bit since Invincea took over SBIE development, but building general-purpose sandboxes is still difficult.

One final note though: if the Chromium sandbox can be invoked on Windows without any special privileges, then Chrome can probably be run under SBIE without any problems, so that does answer one of the original questions here I guess.

 

All they're saying is "Don't start hooking the kernel and trying to enforce our own kernel level policies". They're basically saying "Don't do what sandboxie does [note: it's really *did* as it doesn't anymore, AFAIK]".

 

Doesn't SBIE still work on Windows XP? I know it uses integrity levels on Vista and later, but to work on XP it would have to use a driver. (The "restricted token" sandboxing mechanism does exist on XP, but is only really usable by programs internally AFAIK.)

 

This is what Tzuk said about running Chrome under Sandboxie.

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

Bo

 

I would imagine it depends on the nature of the exploit. An attack against e.g. the infamous font parsing vulnerability, MS11-087, would bypass Chrome, SBIE, and everything else in one go... If it worked. (Which it wouldn't on a current system, because that vulnerability was patched a while ago.)

I'm not going to discount the possibility of SBIE blocking something that the Chrome sandbox doesn't, but I am skeptical since they're both enforced from the same privilege level (regardless of hooks vs. API calls). OTOH Tzuk obviously knows Windows internals better than I do, so...

 

So what is the end conclusion of this thread? Like I said before, I would never rely only on the sandbox of Chrome and IE, I would still choose to use an anti-exe or anti-exploit tool to protect the browser. And because of the huge amount of info in this thread, it´s still not really clear to me if Sandboxie can provide additional security to Chrome, but if you need virtualization you still need SBIE anyway.

 

True, this is why I use MBAE for extra safety for Firefox, IE and Chrome.
But like you said, it's still not clear and it's not been proven that SBIE can provide additional protection for Google Chrome-but they are both virtualization softwares.
So far I have never seen any advantages of SBIE over Chrome when it comes to purely security and protection of Google Chrome browser, to use SBIE on top of Chrome.
When you download files, SBIE4 is the champion here, while Chrome protects against exploits and drive-by downloads.

But SBIE4 also does equally good protect against exploits and drive-by downloads, right?
And the latest answer from Curt from Invincea, I posted this (Bo Elam could also post this) where Curt said that SBIE4's code so far is good and Curt answered: "Nothing has been exploited"-nuff-said.

But I don't think I asked the question before if the way Chrome is suppose to be unexploitable (integrity levels, untrusted/low, whatever, doesn't access the entire Windows read/write file system) is more secure than the method that SBIE4 uses (kernel-mode hooking?).

 

Actually, Chrome did protect against this True Type font vulnerability, but here is the explanation from Curt from Invincea why is that the case:
"I'm bringing this back up because there is still some confusion in various forums.

The particular win32k.sys kernel exploit that Lumberjack is referring to is known as the TrueType Font vulnerability (https://technet.microsoft.com/library/security/ms11-087). The reason that Chrome was not affected by this is because Chrome had their own font parsing library from several years earlier (https://code.google.com/p/chromium/issu ... ?id=146254) that rejected these malformed fonts. So, their code never ran into the vulnerability. And from what I can tell from Chrome's writeup, it looks like Firefox also used the Chrome library so they never hit the bug either.

By the time this bug was made public, the problem had been fixed by Microsoft and a patch released. What our competitor did for their report was to use an unpatched version of Windows. Effectively, they exploited a kernel bug that no longer existed.

So you cannot say that "Chrome can protect against a kernel vulnerability but Sandboxie can't". It just so happens that in this case, they never hit the vulnerability."

 

GJ, just for the record, Invincea posted their own answer to Bromium labs' report about sandboxing, unfortunately I don't have the link, but some here from the thread could post that link in pdf reader I think, this is basically the answer and critics to what Bromium Labs said about sandboxing.
Unfortunately, I don't know who's right or who's wrong, I'll let to Hungry Man, WIndows_Security, you and the rest of techies to decide.

But I don't think I asked the question before if the way Chrome is suppose to be unexploitable (integrity levels, untrusted/low, whatever, doesn't access the entire Windows read/write file system) is more secure than the method that SBIE4 uses (kernel-mode hooking?).

 

On my old Windows XP Professional Service Pack 3 I use both AppGuard 4.1.45.1 and Sandboxie 4.12, just fine, and I'm happy with them (and I do use/I have enabled/checked Drop rights option inside Sandboxie 4.12).

 

This statement by Curt is about the Bromium test and Sandboxie.

http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&p=103163#p103163

Bo

 

@bo elam, interesting about Chrome doing its own font parsing. I wasn't aware that userspace font parsing was even an option on Windows.

I do think it's a bit beside the point though, since the font parser vulnerability is only one of a category of potential bugs that could bypass SBIE (or the Chrome sandbox for that matter). Bugs that would presumably be less effective against a sandbox enforced by a hypervisor, running below the kernel...

(That said, I am not fond of Bromium's marketing tactics from what I have seen of them. The whole "Our security is the BEST EVER, but it's not for public consumption and you have to pay an undisclosed price up front!" schtick gets very old very fast.)

 

Hi, Bo, I was not talking about this, I was talking about detailed analysis of Bromium Labs tests about sandboxing the entire pdf reader (I think it is pdf reader) is all about how Invincea freespace and also, I think, SBIE protect and also the answer and critics to Bromium labs report that sandboxing is completely useless, you should ask Curt to give you the link about this, he should know this.

 

Just wondering, what would happen if I block win32k.sys with SBIE4 restrictions?
Also, on the link Curt gave, the workaround for True Type font vulnerabilities is to block t2embed.dll (which I did long time ago).
Evidence:
https://technet.microsoft.com/library/security/ms11-087

Also, regarding exploits so far I have not seen anything or anyone that was able to infect computer by just using exploit, you need malware to infect computer not exploit, exploit merely open the doors to your OS kernel but ti does not infect you and cannot compromise your OS kernel security since there is nothing you did with exploited OS without using another malicious code-malware, this is why sandboxing, anti-exe plus policy restriction (Sandboxie, AppGuard and NVT Exe Radar Pro) are so much useful all in the same time.

Take True Type font vulnerabilities they still need malware (Duqu malware, to be more precise) to do the malicious action.
Sure there are payloads that do not need execution in memory, but even that can be configured to be blocked (AppGuard's memory guard) as long as there are payloads it should be possible to block them all.

 

So, first off, I should make a disclaimer: I'm not software security expert. My knowledge of this stuff is all theoretical, not practical; my typical day involves nothing lower-level than shell scripts. So you all might want to double-check the stuff I say, just in case. Being thorough doesn't hurt.

Anyway...

@CoolWebSearch the problem is that once a privilege escalation has occurred, kernel security can be bypassed or disabled, and a malware payload can execute undetected. If you run the malware by forcing the kernel to run arbitrary code, there's nothing SBIE, Chrome's sandbox, or anything else can do to stop it.

Sandboxing, trusted path execution, etc. are all enforced from the same software layer. If that layer fails, you lose all of them.

 

The answer to that question.

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

Bo

 

I'm still wondering against what exactly Google Chrome (newest version) would be able to protect and against what exactly Google Chrome (newest version) would not be able to protect that Hungry Man mentioning (attacks, exploits, remote code execution, shellcode attacks and whatever else in that link (http://www.insanitybit.com/tag/exploit/) you gave us?

And what about this, I found this on another forum and on AppGuard sub-forum:
"In another class of attack known as Advanced Volatile Threat, malware does not need to download DLL or EXEs. In a recent Internet Explorer 0-day case, IE itself taken over (when a user simply visits a contaminated Web site) and becomes the harvesting ground for the malware itself. That particular attack, undetected by traditional defenses like AV and HIPS, can create additional malicious code in-memory and perform lateral move to other white listed applications using completely legitimate Windows APIs defeating any defenses. AppGuard prevents the lateral move while white listing is defenseless as there is no DLL or EXE to intercept."

I wonder if Google Chrome can protect/protects against this?
What about EMET and MBAE?

And what about this:
http://web.nvd.nist.gov/view/vuln/search-results?query=chrome&search_type=all&cves=on

Will all of the mentioned CVEs disable Chrome's protection or not?
Some examples:
"Summary: Multiple unspecified vulnerabilities in Google Chrome before 37.0.2062.120 allow attackers to cause a denial of service or possibly have other impact via unknown vectors.
CVSS Severity: 7.5 HIGH

Summary: Use-after-free vulnerability in core/dom/Node.cpp in Blink, as used in Google Chrome before 37.0.2062.120, allows remote attackers to cause a denial of service or possibly have unspecified other impact by leveraging improper handling of render-tree inconsistencies.
CVSS Severity: 7.5 HIGH

Summary: Google Chrome before 37.0.2062.94 does not properly handle the interaction of extensions, IPC, the sync API, and Google V8, which allows remote attackers to execute arbitrary code via unspecified vectors, a different vulnerability than CVE-2014-3176.
CVSS Severity: 10.0 HIGH

Summary: Multiple unspecified vulnerabilities in Google Chrome before 37.0.2062.94 allow attackers to cause a denial of service or possibly have other impact via unknown vectors, related to the load_truetype_glyph function in truetype/ttgload.c in FreeType and other functions in other components.
CVSS Severity: 10.0 HIGH"

Is not this a very strong argument/facts to use SBIE4 over Chrome so that you do not have any kind of these vulnerabilities (because SBIE4 fills the holes of Chrome), and I'm still wondering if any of these vulnerabilities would be able to completely disable Google Chrome (newest version) and its protection?

And if the following is really true (and it is):
Exploit a Chrome tab and you have extremely restricted file-system and registry access (not even read and write for both in all cases), you can't create new processes, can't read the clipboard and and you cannot do many other things that are not mentioned (I wonder what things that might be). Exploit an Anti-Virus and you have admin rights-I wonder if, is newest version of Sandboxie 4 (when properly and tightly configured) is that tough?
What about Sandboxie 3.76?

 

Well, Hungry Man confirmed what you wrote about everything here inside this thread.

 

For the past four years, for security, I used nothing but Sandboxie and NoScript, no antivirus or anything. If your security totally depended on sandboxing files and programs, you would feel confident about SBIE. And you would know that Sandboxie is tough to break.

My formula is simply to run all programs and files sandboxed, for example, if I download a PDF or a video, it will run sandboxed until the day it gets deleted. I don't even have to think about nothing since files are sandboxed automatically. You seen my Sandboxie config files for my computers. I send them to you. You must of noticed that I sandbox a lot of programs, in their own sandbox, each sandbox tailored according to the dedicated program and allow as little as possible to run and connect. Thats all I do, during the 6 years that I used SBIE, I never pondered or ran a scan because I have doubts about SBIE or anything like that. Sandboxie works great.

Bo

 

Windows Security what did you mean by this:
http://forums.sandboxie.com/phpBB3/viewtopic.php?f=6&t=15202

Tzuk, Sandboxie v4 uses policy container with stripped rights (basically NO rights) .
Even Sandboxed Chrome broker process can't touch anything!

What does this in bold mean?
What are you saying?
That SBIE4's policy container operates on lower level than Chrome broker's process?
What do you mean by "sandboxed Chrome broker process cannot touch anything"?
So this means SBIE4 uses even lower Windows integrity levels and it's even more secure than Google Chrome's broker process?
Big thanks in advance.

 

The talk about vulnerabilities and stuff goes beyond my knowledge. I don't know any about such things as how hackers operate.

Normal people use programs like Sandboxie and AppGuard along with their antivirus and don't get injected. If they have vulnerabilities, getting code from websites visited injected etc that this Rasheed is so interested. Targeted hackings are not so much we can do much against.

Best thing is to shut down the computer and then restart. Only one can never know for sure how much damage those injections can do. And nothing is ever for sure.

I would never use some popping up HIPS ever again, gets us paranoid and in the end we cannot operate them.
Just my say in this thread. And what I use is in my signature. It is not meant for some to exploit, I just like to be open, even when posting on sites like wilderssecurity.

 

I think the end conclusion is that the "sandbox" feature offered by Chrome and IE is a cool new feature to harden the browser, but it does not hurt to use an extra layer of protection. Because you never know if malware can use some "privilege escalation" bug to escape the browser sandbox, and then you still need to stop the payload.

And about SBIE, one advantage that it has is the virtualization feature, so if some exploit is running, it can not touch the file system and registry, and also can not communicate with apps running outside the sandbox. So if it does not interfere with the security features of Chrome, why not use it?