[pcwalton]

> Every exploit shop considers Spidermonkey to be a security clusterfuck yet it's still in use.

Can you elaborate why SpiderMonkey is worse than Chakra, JavaScriptCore, and V8?

SpiderMonkey has approximately the same security track record as all of them. I think you're conflating the lack of sandboxing and some mistaken security-related decisions in the Firefox chrome with some sort of intrinsic security problem in the JavaScript engine.

> Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome.

And sandboxing is being actively worked on right now. In fact, it's an utmost priority.

Nobody is talking about doing Quantum instead of sandboxing. Rather, Quantum is being done alongside sandboxing.

> Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security.

I don't agree. Replacing C++ code with Rust code reduces the attack surface. The more of the browser you write in a memory safety language, the fewer opportunities for memory safety holes that attackers have.

Do I want to shrink the trusted computing base as close to zero as possible? Absolutely! But that's a long-term journey, and I would love to see Servo components get some real-world production use along the way.

> At some point people need to realize that one has to scrap the pile of mud and start again, on solid foundations. Alas I feel that these lessons escape the Mozilla folks and thus their browser will remain low hanging fruit for adversaries.

There's only one browser vendor that is actively working on "scrapping the pile of mud and starting again", and it's the browser vendor you're complaining about. You claim that the lessons of security "escape" me, but I have been working day-in and day-out for years on a browser engine written from the ground up in a memory-safe language.

[Eridrus]

Do you see sandboxing at odds with performance? I know it causes a hit to RAM, but I have no sense for impact on CPU usage or user responsiveness metrics.

Once sandboxing is implemented, will there be a push to implement the privileged process in Rust?

[armitron]

It's not just the lack of sandboxing, Spidermonkey is qualitatively worse than V8. The metric used is ease of finding exploitable bugs _without taking sandboxing into account_. I do not know where you get your security track record from, but there is a big asymmetry in public-vs-private information on the matter. Most of the research into exploitation happens behind closed doors and the general public is not privy to it.

Reducing the attack surface is meaningless when the attack surface is humongous, yet people keep reiterating the same old fallacies.

Mozilla has said nothing about starting again on solid foundations. All I see are iterative improvements on top of the same, rotten core, with an emphasis of performance to boot. This is not progress.

[pcwalton]

> I do not know where you get your security track record from, but there is a big asymmetry in public-vs-private information on the matter.

No, there isn't. Security bugs are made public in both Bugzilla and chromium.org once enough time has passed. Both engines have been around for years and years, so there's been plenty of time to gather data.

Sorry, but I'm not going to just trust "I can't link to anything because it's secret".

The only security-related feature that V8 has that SpiderMonkey doesn't is limited constant blinding in the non-optimizing JIT only. This is a cosmetic feature that does little, because an attacker can trivially subvert it. See: https://bugzilla.mozilla.org/show_bug.cgi?id=677272#c58

> Reducing the attack surface is meaningless when the attack surface is humongous, yet people keep reiterating the same old fallacies.

How are we going to get the attack surface down unless we reduce it?

> Mozilla has said nothing about starting again on solid foundations.

1. What do you think Servo is?

2. Who else is talking about "starting again on solid foundations"?

[Eridrus]

Bugs are only made public when developers find out about them then fix them. Many exploits simply die to code churn rather than developers actually fixing what they understand to be a vulnerability.

I have no horse in this race, but I don't think you should assume you have all the information.

[Eridrus]

My knowledge may be out of date, but afaik one example of SpiderMonkey being worse is that it requires manually rooting objects; I don't think Chakra or v8 have this manual requirement that leads to security vulns.

[armitron]

> How are we going to get the attack surface down unless we reduce it?

Ideally you never introduce it. Alternatively, you never let it get to the point where getting it down is essentially a no-op.

>> Mozilla has said nothing about starting again on solid foundations.

> 1. What do you think Servo is?

A research project in a Mozilla lab that is not fully embraced yet. Parts of it may, slowly, end up in Firefox. How does this improve matters or introduce solid foundations? I have yet to see a concrete commitment from Mozilla that Servo will be fully utilized in Firefox. Even the linked article demonstrates the opposite. Even so, let us assume that Firefox uses Servo. We're still in security hell due to SM.

> 2. Who else is talking about "starting again on solid foundations"?

In practice, Microsoft did tremendous work with Edge.

Chrome is not perfect, but is as close to perfect as you can get while still using rotten tools (C++).

There is a shift inside Apple too. We will see how it manifests.

[pcwalton]

> Ideally you never introduce it. Alternatively, you never let it get to the point where getting it down is essentially a no-op.

I can't understand this logic at all. You seem to be denying that you can ever reduce software attack surface in existing software, which is obviously false. It's undeniable that seccomp-bpf dramatically reduced attack surface in the Linux kernel, for example.

> A research project in a Mozilla lab that is not fully embraced yet. Parts of it may, slowly, end up in Firefox. How does this improve matters or introduce solid foundations?

I would think the important thing that determines whether we're developing the software is whether we're developing the software, not whether there are immediate product plans. By that logic, AT&T never developed Unix.

> Even so, let us assume that Firefox uses Servo. We're still in security hell due to SM.

No. I've already explained why this is incorrect. Switching to V8 would make negligible if any difference in terms of security.

> In practice, Microsoft did tremendous work with Edge.

EdgeHTML is a fork of Trident! Its development was not "starting again on solid foundations"!

> Chrome is not perfect, but is as close to perfect as you can get while still using rotten tools (C++).

Chrome is a fork of WebKit, which is a fork of KHTML! Its development was not "starting again on solid foundations"!

[Manishearth]

> Even the linked article demonstrates the opposite

No it doesn't. Servo is still chugging along. Firefox wants to get Servo's advances early.

> I have yet to see a concrete commitment from Mozilla that Servo will be fully utilized in Firefox.

Because Servo is a long term project. And writing a new browser engine is hard, if you want to be 100% web compatible. Servo's getting there, but it will take time.

> We're still in security hell due to SM.

No it doesn't. Content sandboxing is being actively worked on. Even if not, pcwalton already mention that SM and V* are roughly on par wrt safety features (aside from sandboxing).

> Alternatively, you never let it get to the point where getting it down is essentially a no-op.

You have yet to demonstrate why you think Firefox's attack surface is that bad. You linked to a blog post which uses this (http://cyber-itl.org/blog-1/2016/8/12/our-static-analysis-me...) metric, which is light on the specifics (or reproducability). ASLR and content sandboxing may be enough to bump Firefox back to the top. There's nothing there to convince us that the metric used maps well to real-world exploitability.