Pwn2Own 2014 Claims IE, Chrome, Safari and More Firefox Zero-Days | Hacker News Reader

Pwn2Own 2014 Claims IE, Chrome, Safari and More Firefox Zero-Days

eweek.com

58 pointsmikevm27 comments

Mozilla really needs to add its own sandboxing system. Even Chris Soghoian from ACLU says that right now it's hard to simply recommend Firefox over Chrome, because Firefox may be better privacy wise, but it's not better security wise.

So we are down to a "choose your favourite rapist" situation.

Indeed. It's the only reason I stick with chrome even though I desperately want to find an alternative. I cringe every time mozilla launches yet another overly ambitious project while their market share in their core product continues to decline and glaring issues with their browser persist. I don't know how their strategy will play out for them but I'm not optimistic.

Worry not, it appears that they are working on it.

https://wiki.mozilla.org/Sandbox

https://bugzilla.mozilla.org/show_bug.cgi?id=925570

And it's already enabled in Firefox OS on devices that have seccomp support in their kernel.

You can try Firefox's sandbox code (work in progress) in Firefox Nightly channel (30). Then invoke the File > New e10s Window command. No about config magic.

I use Nightly and I hadn't noticed that, so I tried it; an alert opened:

> To use out-of-process tabs, you must set the layers.offmainthreadcomposition.enabled preference and restart. Opening a normal window instead.

So it does actually require a about:config tweak to enable it.

Sorry, I forgot that Linux and Windows need off-main-thread composition (OMTC), which is already enabled by default on OS X.

* Linux OMTC: https://bugzil.la/722012 * Windows OMTC: https://bugzil.la/913249

A sandbox is just code and code has bugs. As was said in the article you can escape the sandbox.

That's actually the point of a sandbox. Code has bugs, so you sandbox it.

Now, the sandbox is also code, but to my understanding it's fewer LoC than what you are sandboxing. As bug rate per LoC is a fairly stable value, reducing LoC reduces total bug count. Ergo, by wrapping a large complex program with many LoC inside a small sandboxing function, you increase security (though it is not perfect, it still will have SOME bugs)

The amount of unsandboxed code in Chromium is not a whole lot smaller (if at all) than the amount of sandboxed code on a lines-of-code basis. The advantage of sandboxing is that most of the code that directly interacts with content (the rendering engine) is prevented from directly performing malicious actions, assuming the sandbox is secure.

That's like saying locks are one more thing that can be broken, just like the doors. So why do people have locks on doors - in security you put up as many deterrents as practical and hope one of them saves the day. It's generally worth it.

I don't think "security" is usually a binary concept, where it's either there or it isn't. It's more useful to draw an analog from the ratings of safes, which are along the lines of "it would take ___ hours / days to break this safe." Instead of lofty claims about being impervious to attack, put up obstacles and hurdles, that make attacks harder.

But those "obstacles" and "hurdles" can themselves be exploited in some cases. If they're software-based, then they can just end up making the attack surface much larger.

Google's Chrome Web browser was successfully exploited by VUPEN on March 13 with a use-after-free memory flaw that enabled a sandbox bypass.

Am I right in thinking that would be only the second Chrome exploit that escape the sandbox (if we ignore exploits that relied on plugins)?

Pinkie Pie already achieved full sandbox escape in Chrome at least twice in Pwnium.

Yeah, but what about Lynx? Nothing? DIDN'T THINK SO! HA!

I wonder if you could exploit Lynx with an SSL bug, given that it is the most complex protocol it handles.

Of note: the Firefox vulnerabilities were all buffer overflow related.

AKA, not possible in Rust...

Mozilla's post from the March Who's Hiring thread:

"Servo is a new web browser engine. It is designed to be more memory safe (far and away the #1 cause of browser engine security bugs!) through use of the new Rust programming language"

They're trying. They're on it, you know? They need more talent sent there way I suppose.

"To be very clear: Servo is a research project. It is not aimed to replace Gecko. It gives us the opportunity to experiment with new approaches, new patterns and new technologies, like Rust, another research project we are working on." (Emphasized in original)

http://paulrouget.com/e/servo/

Any idea when this will be applicable to real world Firefox?

The party line from Mozilla is that Servo will never replace Gecko, so... never?

That is what I have read. When I saw your post I thought/hoped there was a new development.

Not all of them. One was a use after free, which isn't related to buffer overflows. Two other ones are not clear what they were caused by:

By Mariusz Mlynski:

Against Mozilla Firefox, two vulnerabilities, one allowing privilege escalation within the browser and one bypassing browser security measures.

http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Pwn2O...

Whoops, thanks. That one is also not possible in Rust, so my point still stands. ;)

Use-after-free is also prevented by Rust.

Reply on news.ycombinator.com