I would sure love to know a bit more about this POC, because if it's true, then it confirms what I already thought, namely that SBIE is not automatically defeated when malware has somehow managed to elevate to high privileges, inside the virtual container. This means that SBIE is at least able to put up a fight in case a kernel mode exploit is used. Chrome isn't able to do this, not surprisingly.
Yup, people seem to forget that SBIE is in fact a virtual container, it doesn't try to stop the exploit itself, it will try to contain the malware in case the browser is successfully exploited. In the link you can find some high risk bugs that could have lead to attacks on Chrome with code execution as result. Of course, Chrome's sandbox was designed to make it harder to exploit, which is a good thing. http://www.cvedetails.com/vulnerabi...24/product_id-15031/opec-1/Google-Chrome.html
Well, that's your opinion but all security experts think different. Some basic reading: https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet https://www.sans.edu/research/security-laboratory/article/did-attack-surface http://resources.infosecinstitute.com/attack-surface-reduction/ And again, it's not only theory: http://www.computerworld.com/articl...products-are-riddled-with-security-flaws.html
You have to be kidding me. I'm not talking about "attack surface" in general. I'm talking about attack surface in the context of SBIE being a risk to Chrome instead of being a benefit. Just read the post to see what I mean. About AV's, I think I have read about this at least 8 years ago, but you never hear about any real life attacks, so I'm guessing it's not that easy to exploit.
Well, I already gave you the links about this: https://www.wilderssecurity.com/threads/chrome-sandboxed.377440/page-5#post-2506278 http://arstechnica.com/security/201...y-potent-enough-to-infect-actual-chrome-user/ http://arstechnica.com/security/201...mergency-flash-patch-for-hacking-team-0-days/ And here is what Curt answered on Sandboxie forums: http://forums.sandboxie.com/phpBB3/viewtopic.php?f=17&t=21411#p110798 Here is Curt's response: And the fact is everyone on this thread is ignoring these facts, Windows Security, Hungry Man, Safeguy, they all talk about about Sandboxie weakening Chrome, and yet in this particular case where the kernel exploit is able to successfully bypass all of Chrome's sandbox hardened defenses is actually blocked,protected and contained by Sandboxie so that the rest of the real computer system is 100% secured. Obviously Sandboxie does not weaken Chrome at all, not even the slightest, Sandboxie protects Chrome. I mean Bo Elam wrote about this in the very first page of this thread and everyone, including all the experts ignored his posts about this particular kernel exploit that bypasses all of Chrome's sandbox hardened state-of-the-art defenses, and yet this same kernel exploit does not bypass at all Sandboxie that protects and runs on top of Chrome and its own built-in sandbox.
CWS, for the most part, only non Sandboxie users ignore what I quote from Tzuk, Curt and the Sandboxie forum. A couple of this guys, using fancy language to bang on SBIE, sounds technical, but as I read what they write, its clear they have no clue how to properly use Sandboxie, when to use Sandboxie and when not to use SBIE. One of this guys complained at me for posting quotes from Curt and Tzuk. Thats a pretty Smartguy. This is a thread about SBIE but this guy don't want to see nothing get quoted from the Sandboxie forum. Follow your instincts on what to do (to sandbox or not to sandbox Chrome) and stick to it. Bo
I will ask for some more info on the SBIE forum. I think it all depends on how advanced kernel exploits are, in some cases SBIE might indeed still be able to protect the system. And I don't believe this is being ignored by guys like Hungry Man and Safeguy, but they just wanted to point out that in theory SBIE might be a risk to the robustness of Chrome's sandbox. There's nothing wrong with saying this, but like I already explained, in real life SBIE is more likely to be a benefit than a risk to Chrome (and any other browser). I do wonder if they will perhaps make a comeback in this topic, I would still like to have an answer on my last question.
I don't often come on here, and I rarely read topics. So if you want my attention use the alert system @Hungry_Man or whatever - it's the easiest way to make sure I'll at least read your post next time I log in. Anyways, Sandboxie does not protect against the exploit. It protects against the payload, which I think I've already covered - it only 'protects' it due to the payload not caring about Sandboxie. If it did, it would have no trouble getting out.
OK thanks, so we are on the same page. But it's interesting to me that the payload was able to elevate to high or system integrity, and even then it was stuck in the sandbox. So that alone isn't enough to defeat the sandbox. I read a similar thing in the Bromium report. And what do you think about this (see quote), does it make sense, or am I missing something?
Was that an automated exploit they released ITW before being patched, or something specifically designed to target high-profile users? I knew Flash was a liability on Chrome, does that mean click-to-play and standard URL filtering is not enough? Anyhow, I'd actually use SBIE on Chrome (especially with plugins) in light of something like this, if not for the anti-exploit tools we have these days being easier to setup.
The payload is not stuck. It's just in the sandbox. It can leave, it just doesn't because it doesn't know to - if it did, which it could, it could then leave. Otherwise yes. Probably not. A program in a Bromium sandbox is stuck even if they do have kernel privileges. This is because Bromium utilizes virtualization at a hardware level. What Bromium was probably trying to explain is what I'm trying to explain - once the attacker is in the kernel, unless you're in the hardware they can escape. I agree, unless the attacker were targeting a specific group like a company that has it deployed. If they knew the company used Sandboxie they could target their attack. But that's security through obscurity, which is fine if that's what you want. It'll be effective against the general threat landscape you are likely to come across. If it's come across like I think there's any serious risk running Chrome in Sandboxie, trust me, that isn't the case. It's irrelevant for users. Only if you're worried about advanced threats is it worth really thinking about this, in which case conjecture would be the least effective approach.
What about "Chromium Win32k renderer system call lockdown"? It should make Chrome's sandbox very hard to exploit, combine this feature with Google's bug bounty and we have a strong secure browser by default. IMO Sandboxie is a great piece of software but it doesnt do much for Chrome users using Windows 8 (or 10).
What would be really interesting instead of all these 3rd-party tools, is how something like AppContainer would factor in advanced threats like those. Too bad I can't even try it on Windows 10... Does anyone know the follow-up to this "fixed" bug?: https://code.google.com/p/chromium/issues/detail?id=470227
Sadly, security through obscurity may still have its points (though I'd hesitate to call them virtues). e.g. I recently got to see what I'm pretty sure was a compromise on my router PC - running a firewall distro with a GrSecurity patched kernel. Reboots I didn't ask for, shellcode detections in the Snort logs, Internet connection not working, and three days of system logs missing. My rubbishy old Dynex router OTOH has never been compromised, at least not in any way I could measure. Security by design is a good thing. But when there are zero-days galore flying around for the relatively secure modern stuff; and nobody is even bothering to attack the relatively insecure archaic stuff... well, yeah. The situation is pretty bad. ... That said, if I really wanted to go the "secure by obscurity" route, I wouldn't bother using Windows in the first place. (Classic Mac, anyone? )
OK, thanks. Did Google Chrome and all other web-browsers fix this vulnerability or bug whatever? And I wonder if anti-exploit tools like HMPA and MBAE would protect against this, since this is kernel exploit, I'm not that sure at all.
Of course, Adobe already patched it. Keep it up-to-date, in which browsers, OS, and Flash control panel do automatically these days. https://www.wilderssecurity.com/thre...iscussion-thread.324841/page-258#post-2506192 https://www.wilderssecurity.com/posts/2504672/
Wait a minute, what are you trying to say that this exploit I was talking about the last 2 pages did not break through Chrome's sandbox indirectly and directly at all, but through one of Google Chrome's vulnerable points-Flash player That's not the same as saying that Google Chrome's sandbox itself directly was bypassed/broken without using vulnerabilities in plugins-that's a collossal difference, it means that Chrome's sandbox itself was not bypassed at all, Chrome's sandbox was not even targeted (but since this is a kernel exploit, I wonder if it's useless to talk about that Chrome's sandbox was not bypassed at all-since this is kernel exploit we are all talking about). I hope Hungry Man can shed some light on this question...
@Gullible Jones Ah, yes. I read your email by the way, just got swamped and didn't get to reply before it sank into the depths of my inbox. Security through obscurity is the thing that keeps 99% of the world safe. I think attackers and the threat landscape are moving towards campaigns targeted towards enterprise where the gains are massive. @CoolWebSearch They'll do nothing to stop the kernel exploit.
Yes, this is what I've been saying all along. If the payload escapes from Chrome's sandbox it's game over, but SBIE is actually an isolating layer on top, so you need to bypass that also. In the Bromium report you could read that simply elevating to system privileges was not enough to defeat SBIE, it would still block the payload from certain dangerous actions, so I'm guessing that SBIE blocks certain stuff regardless of privilege level. Earlier in the thread we had a bit of a discussion about this. Yes exactly, but these kind of hackers probably don't even need the "added attack surface", they could use a browser + kernel exploit, to bypass both Chrome and SBIE. I do wonder though how serious the risk is of kernel exploits, you would think that hackers will start to focus on it a lot more, especially now browsers like Chrome and Edge are quite hard to hack with regular user mode exploits.
Kind of figured that's what happened. But yeah, from what I saw, it seemed like GrSec-bypassing, zero-day remote kernel exploits are now being used in automated attacks against Internet facing Linux systems. (The Snort logs showed shellcode from a bunch of weird domains on port 80, just before the missing log period. At a guess I'd say, watering hole attack on one of my client machines => some kind of exploit kit => OS fingerprinting notices my router runs Linux => sending a Linux zero-day at it. Pretty sophisticated, but probably quite possible to automate, provided one has the zero-day exploit.) I suppose. Scamware still makes a lot of money though. Although, it now strikes me that using a hardened Linux router might have made me look like a small business (and thus a juicy target).
Yes, all the links you posted has the word "Flash" in it. But that built-in plugin is supposed to be protected by Chrome's sandbox. What about the links I've posted where the makers of HMP.A and MBAE both say they protected against that exploit? Although I'm not sure which Flash exploit is the kernel exploit...