I think it's clear that we need to have more discussions with Richard and his team to work through the security constraints more and figure out the best path forward. As a member of TC39 and a participant in the discussions about SAB, I apologize that I didn't more proactively contact Richard (I mentioned it to ekr but didn't follow up aggressively enough).
So far I don't see enough evidence to assume we're in an either-or situation. Security and multicore capabilities are both shared goals we all have, and until we've exhausted all options for win-win outcomes, I'm not jumping to a zero-sum outcome. In particular, a) I don't know without a better understanding that the current 5µsec is a for-all-time constraint or a current-state-of-things constraint, and b) I don't have the expertise to know that an "information leak problem" is mild enough to declare that "the evolution of the web platform" demands full speed ahead without thorough review from our security experts. Examples of win-win options: prioritizing the work needed to eliminate the 5µsec constraint and unblock SAB, and/or releasing throttled versions of SAB until that work can complete. These are just examples based on my admittedly incomplete understanding of the underlying constraints. No matter what, we need a better reckoning with those constraints. Dave On Fri, Mar 4, 2016 at 4:39 AM, Lars Hansen <lhan...@mozilla.com> wrote: > I hope I didn't suggest that people should stop discussing it; all I wanted > to do was to lay out the background for the debate and the evidence that > has been presented so far, in particular given Richard's strong assertions > about what this attack is able to do in JS, in a browser - which in truth > is "not much yet". > > I don't think I'll be able to convince the people who are concerned about > this. The facts are pretty clear - shared memory can be used to build a > high-precision clock, and some attacks, whether existing or hypothesized, > will only work with such a clock. I think it's important that this is not > a weakness that is unique to this particular spec since such clocks can be > built in other ways, using both aging and emerging technologies (Flash, > WebAssembly). > > To the extent I want to convince anyone at all, it is to convince the > people who will ultimately make the decision to enable the feature, > balancing a possible information leak problem against the evolution of the > web platform. > > --lars > > On Fri, Mar 4, 2016 at 1:08 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > > On Thu, Mar 3, 2016 at 11:39 PM, Lars Hansen <lhan...@mozilla.com> > wrote: > > > >> On Fri, Mar 4, 2016 at 1:41 AM, Richard Barnes <rbar...@mozilla.com> > >> wrote: > >> > >> > Another good reason for blocking this for now is that it lets > Javascript > >> > circumvent the 5usec granularity of performance.now() and do things > like > >> > stealing private keys. > >> > > >> > https://www.w3.org/TR/hr-time/#privacy-security > >> > http://iss.oy.ne.ro/SpyInTheSandbox.pdf > >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1252035#c9 > >> > > >> > We must not turn this on by default in any branch other than Nightly > >> until > >> > we can assure that the 5usec boundary will be maintained. > >> > > >> > >> I think your conclusion is bold, given the available facts: > >> > >> The papers that have been published so far have not shown any evidence > of > >> doing "things like stealing private keys" in JS. The papers that have > >> made > >> use of JS have so far demonstrated the ability to discern user activity > >> (the spy in the sandbox paper) and the ability to flip a bit in memory > >> without making use of that capability for anything specific (the > >> rowhammer.js paper). Of course we must expect these attacks to improve, > >> but so far they are not doing anything akin to stealing private keys > from > >> JS. > >> > >> The 5us timer may itself not hinder these attacks and should not be > >> treated > >> as some kind of "safe" limit. The spy in the sandbox paper states that > a > >> 1us resolution is enough for that attack; I have made an argument, with > >> code (https://github.com/tc39/ecmascript_sharedmem/issues/1), that a > 1us > >> timer can be constructed from a 5us timer without the use of shared > >> memory, > >> the Tor project has reached a similar conclusion ( > >> https://trac.torproject.org/projects/tor/ticket/16110). The > rowhammer.js > >> authors have stated (in a talk) that the 5us timer is not a hindrance > for > >> their attack. > >> > >> As I have written about elsewhere ( > >> > >> > https://github.com/tc39/ecmascript_sharedmem/blob/master/issues/TimingAttack.md > >> ) > >> there is every reason to believe that high-resolution timers can already > >> be > >> constructed by various kinds of content in web browsers. > >> > > > > I'll have more to say about this soon, but I don't think this argument is > > dispositive, > > given that essentially all of the technologies that provide these > > capabilities > > (Flash, Java, ActiveX, ...) are ones we are trying to eliminate. > > > > > > It is reasonable to be concerned for this capability but it has been > >> debated at some length; Chrome's security team is on the record (at the > >> last Ecma TC39 meeting) as being able to live with it (I'm paraphrasing, > >> as > >> I don't have the text of their statement); > >> > > > > I realize it's been debated at length, but it's not my sense that you've > > actually > > convinced the people who are concerned about this. Also, surely you're > not > > suggesting that the Chrome security team's analysis is dispositive and > that > > the Firefox security team (in this case, Richard) shouldn't make their > own > > analysis. > > > > -Ekr > > > > > > > > (We've found no good mitigations for the issue, and there's no reason to > >> believe that any will be found. Thread pinning might work in some > >> high-security environment, on platforms where that has teeth. User > opt-in > >> seems tricky and opt-in doesn't work well anyhow - most users enable all > >> plugins everywhere, for example.) > >> > >> Your request to "not turn this on ... until we can assure that the 5usec > >> boundary will be maintained" is a request not to turn this on, period. > >> > >> --lars > >> > >> > >> > > >> > --Richard > >> > > >> > > >> > On Fri, Jan 15, 2016 at 12:10 AM, Lars Hansen <lhan...@mozilla.com> > >> wrote: > >> > > >> >> It's not enabled by default because the API is probably not fully > baked > >> >> yet; until the spec reaches Stage 3 at TC39 we should expect things > to > >> be > >> >> fluid. I don't expect that milestone to be reached until this > summer. > >> >> > >> >> We've discussed enabling by default on Aurora, DevEd, and Beta once > we > >> >> reach Stage 2 at TC39, but I don't own that decision, can't guarantee > >> it, > >> >> and might even argue that it would be better to wait a couple of > months > >> >> after reaching Stage 2, which is when the spec gets serious attention > >> from > >> >> the committee. > >> >> > >> >> Google has what I understand to be a compatible implementation of the > >> >> current spec, also available behind a pref (actually behind two of > them > >> >> last I heard). > >> >> > >> >> --lars > >> >> > >> >> > >> >> On Thu, Jan 14, 2016 at 10:24 PM, Robert O'Callahan < > >> rob...@ocallahan.org > >> >> > > >> >> wrote: > >> >> > >> >> > Sounds good to me too. What's blocking us from enabling by default? > >> >> > > >> >> > Rob > >> >> > -- > >> >> > lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe > >> >> uresyf > >> >> > toD > >> >> > selthor stor edna siewaoeodm or v sstvr esBa kbvted,t > >> >> > rdsme,aoreseoouoto > >> >> > o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or > >> rnea > >> >> > lurpr > >> >> > .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt > >> >> sstvr > >> >> > esn > >> >> > > >> >> _______________________________________________ > >> >> dev-platform mailing list > >> >> dev-platform@lists.mozilla.org > >> >> https://lists.mozilla.org/listinfo/dev-platform > >> >> > >> > > >> > > >> _______________________________________________ > >> dev-platform mailing list > >> dev-platform@lists.mozilla.org > >> https://lists.mozilla.org/listinfo/dev-platform > >> > > > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
