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. WebAssembly, to be more than a diverting experiment, will also need to adopt shared memory and will run into the same problem in the future (as has PNaCl in the past). 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); and it is hard to see how the web will evolve as a software platform without a shared memory and multicore capability as part of its standard toolbox. (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
