A Quantum Leap for the Web • Hacker News Board

Re: A Quantum Leap for the Web

#111

Post by pcwalton » Fri, Oct 28, 2016, 1:33 AM UTC

armitron wrote: post #110

pcwalton wrote: post #105

Earlier quoted context omitted.

> 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 t…

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…

> 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"?

Re: A Quantum Leap for the Web

#112

Post by Manishearth » Fri, Oct 28, 2016, 1:35 AM UTC

armitron wrote: post #109

Manishearth wrote: post #107

Earlier quoted context omitted.

> Multiple processes do absolutely nothing for security unless combined with sandboxing ala-Chrome. Seems like sandboxing exists (in some form) and is part of the plan? https://wiki.mozilla.org/Electrolysis#Security_Sandboxing > Continuing to use C++ rather than fully embracing Rust (or something even better than Rust) also does nothing for security Rewriting Spidermonkey in Rust is a major project in itself. JS engi…

They do seem to have Chrome-style Sandboxing in-progress, I guess we'll see how it turns out. 0day being used by various parties is exactly what I'm talking about here. Most of it will not get patched anytime soon and I dare say is orders of magnitude "bigger" than the exploitable bugs that are reported and patched. Yet you don't seem to break a sweat about it, in fact you are comfortably dismissing it under "malicio…

> Note that I did say "Sandboxing ala-Chrome". The link you used demonstrates sandboxing for _plugins only_ which is practically useless, most of the Firefox 0day I've seen goes after Spidermonkey.

No, the link mentions "Content" all over the place, which is websites (and IIRC SM runs in the same process). It seems to be a work in progress, but that was all I was going for.

> And 0day being used by various parties is exactly what I'm talking about here. Most of it will not get patched anytime soon and I dare say is orders of magnitude "bigger" than the exploitable bugs that are reported and patched. Yet you don't seem break a sweat about it, in fact you seem comfortable dismissing it under "malicious parties".

No, I focused on patched exploits because IMO they can cause more harm (especially to users who don't get the patch in time) over zero days. Zero days can still cause harm, but because they're hoarded it's often less harm -- they can mostly be used in targeted attacks, since in broader attacks it's less likely for them to work under the radar (and stay unpatched). I could be wrong here, sure (and whether targeted attacks are less harmful than broad ones is debatable too, since targeted attacks generally do much more). But I'm under the impression that 0 days in SM (or indeed any software) are not as common as you seem to believe (of course, data on this will be incomplete). Hence I focused on patched exploits (not knowing that you were talking about 0 days in particular).

I was not breaking a sweat about either type of vulnerability because content sandboxing is something being worked on. These vulnerabilities are still bad with sandboxing, but it no longer is something that is hard to incrementally improve on.

Re: A Quantum Leap for the Web

#113

Post by pcwalton » Fri, Oct 28, 2016, 1:39 AM UTC

cgag wrote: post #98

pcwalton wrote: post #18

Earlier quoted context omitted.

Servo is still being developed with the same manpower. Quantum is not de-emphasizing Servo. It would make little sense to do so, since the lack of legacy in Servo is part of what has given us the freedom to experiment with things like parallel restyling in the first place. And Quantum helps Servo, too—by giving us real-world Web compatibility experience with portions of Servo's codebase sooner, it helps us shake out…

It would make no sense to de-emphasize servo. It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo. I hope that either mozilla is lying for political reasons about their lack of intent to use servo outright, or that the servo team forks from mozilla and takes funding from patreon (or snowdrift when it launches) and builds som…

> It seems like it would make a lot of sense to de-emphasize Quantum/firefox/everything mozilla is wasting their time and money on that isn't Servo.

Here's how I think of it: What's the biggest risk to Servo? I think most people would answer that (besides it being a lot of work), as it's a big boil-the-ocean project, there's a lot of newly-written code that hasn't been battle-tested yet. How do we fix that? By getting early user adoption on pieces when they're ready, so we can shake out the issues. Quantum is the perfect way to do that.

Of course, I happen to care about Firefox's success too, so getting great features to Firefox users as soon as possible is also a big win from Quantum. :)

Re: A Quantum Leap for the Web

#114

Post by armitron » Fri, Oct 28, 2016, 1:42 AM UTC

pcwalton wrote: post #111

armitron wrote: post #110

Earlier quoted context omitted.

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…

> 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…

> 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.

Re: A Quantum Leap for the Web

#115

Post by armitron » Fri, Oct 28, 2016, 1:51 AM UTC

Manishearth wrote: post #112

armitron wrote: post #109

Earlier quoted context omitted.

They do seem to have Chrome-style Sandboxing in-progress, I guess we'll see how it turns out. 0day being used by various parties is exactly what I'm talking about here. Most of it will not get patched anytime soon and I dare say is orders of magnitude "bigger" than the exploitable bugs that are reported and patched. Yet you don't seem to break a sweat about it, in fact you are comfortably dismissing it under "malicio…

> Note that I did say "Sandboxing ala-Chrome". The link you used demonstrates sandboxing for _plugins only_ which is practically useless, most of the Firefox 0day I've seen goes after Spidermonkey. No, the link mentions "Content" all over the place, which is websites (and IIRC SM runs in the same process). It seems to be a work in progress, but that was all I was going for. > And 0day being used by various parties is…

> No, the link mentions "Content" all over the place, which is websites (and IIRC SM runs in the same process). It seems to be a work in progress, but that was all I was going for.

You are right, I've updated my post.

Re: A Quantum Leap for the Web

#116

Post by pcwalton » Fri, Oct 28, 2016, 1:55 AM UTC

armitron wrote: post #114

pcwalton wrote: post #111

Earlier quoted context omitted.

> 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…

> 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 do…

> 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"!

Re: A Quantum Leap for the Web

#117

Post by Manishearth » Fri, Oct 28, 2016, 1:55 AM UTC

armitron wrote: post #114

pcwalton wrote: post #111

Earlier quoted context omitted.

> 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…

> 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 do…

> 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.

Re: A Quantum Leap for the Web

#118

Post by bzbarsky » Fri, Oct 28, 2016, 3:10 AM UTC

leeoniya wrote: post #64

bzbarsky wrote: post #42

Earlier quoted context omitted.

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(

> Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" woah! that's truly tragic. at the risk of ruining the rest of my week, may i ask where?

Sure. https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the pieces of that spec that use it is the main place so far. There is also discussion about maybe using the same switch in https://github.com/whatwg/dom/issues/278 if it turns out that too many pages assume "not webkit" means XMLDocument.load exists.

It could be worse. When the ECMAScript committee discovered that parsing for function-in-a-block differs between browsers and that sites sniff and do different things in different browsers such that none of the browsers can change to each other's behavior, they went ahead and specified a "compatible subset" of behavior such that if you follow those rules you will get the same behavior in all browsers. That's fine, but if you _don't_, as web pages do not, then you're back to square 1: pages sniff and do different things. And the details are not written down anywhere, so a new implementation has no choice but to try to reverse-engineer the sniffing somehow and then also reverse-engineer the actual runtime behavior of function declarations of whatever browser's sniffing response they decided to fake. The good news is that this function-in-a-block thing is literally the worst situation I have encountered in web standards, so all the other ones suck less. ;)

Re: A Quantum Leap for the Web

#119

Post by bzbarsky » Fri, Oct 28, 2016, 3:14 AM UTC

Aldo_MX wrote: post #73

bzbarsky wrote: post #42

Earlier quoted context omitted.

Compatibility in new engines is ... hard. Servo is basically going to need to spoof the WebKit UA and duplicate a bunch of WebKit bugs (the Edge approach) or spoof the Gecko UA and duplicate a bunch of Gecko bugs. Some specs now have an explicit "does your UA say you are Gecko, or does it say you are WebKit" switch with behavior specified for both branches. :(

Considering that Servo is an embeddable engine, why not keep the scope of Servo focused in building a standards-compliant engine? Replicating other engine's bugs sounds like too much effort towards the wrong direction :/ Although, after the -webkit-disaster I don't really expect anyone to like the idea of a standards-compliant engine :(

> why not keep the scope of Servo focused in building a standards-compliant engine

It depends on how you define standards-compliant.

> Replicating other engine's bugs sounds like too much effort towards the wrong direction

Well, web pages depend on those. So your options are either to standardize them or to have a standard that, when implemented, gives you a non-working product.

In practice, they're being standardized (just like XMLHttpRequest was a non-standard thing that ended up getting standardized). See https://compat.spec.whatwg.org/ and https://html.spec.whatwg.org/multipage/webappapis.html#conce... and the bits of the HTML spec that reference it, the bits of https://drafts.csswg.org/cssom/ that mention "webkit", and so forth.

So in the end, a "standards-compliant" engine will implement those standards, which are themselves to some extent a codification of old implementation bugs; pretty normal for standards...

Re: A Quantum Leap for the Web

#120

Post by bzbarsky » Fri, Oct 28, 2016, 3:24 AM UTC

aikah wrote: post #67

yalooze wrote: post #10

Does anyone know how this compares to the current implementations of competing browsers? ie. is Firefox still playing catch up in some respects or is this leaps ahead of the competition too?

Here my experience with the current Firefox compared to Chrome : - Firefox consumes way less ressources than Chrome. I can open 20 tabs it will consume a reasonable amount of memory. - Firefox crashes way more often than Chrome. I get a crash everyday mostly because of a aggressive Javascript found in pages riddled with ads that abuse tricks in order to force the viewser to see ads ( Adblock can help ) - Firefox is w…

> Firefox is way slower when it comes to Javascript execution than Chrome

If you have specific pages where you're seeing this, please file bugs on Firefox and add "bzbarsky" to the cc list for the bug!