Thanks for your report. Just to let you know, (P)NaCl has been deprecated and its support will be removed in Q1 2018: https://developer.chrome.com/native-client/migration.

CC'ing more folks who can be interested / may help triaging this.

(Although (P)NaCl is on the way out, wasm and SharedArrayBuffer and friends are on their way in and the paper mentions them briefly.)

On the crypto side of things, I think it's generally accepted that crypto code should be resistant to timing side channels and that this includes memory access patterns. I think End-To-End's table lookup in their modular exponentiation should be considered a bug to be fixed there. (Though, yes, high-level languages in general, JS or even C, do not have a way to express these constraints, so crypto code is sadly often at the mercy of the compiler.)

This seems to match the conclusions in the paper as well?

The alternative worldview where we decide web content must never get access to sufficiently performant ways to run code seems hard to justify to me.

bradnelson@ -- assigning to you based on some of the other bugs in the component.
If you are not the right owner, could you please help find the right owner? Thanks!
- Secondary Security Sheriff

Please be advised that putting puns in your paper's subtitle is very enjoyable. :)

Calling it Medium, but I'm open to arguments otherwise.

+somogyi since I agree with #4 that E2E might have a bug to fix. Please feel free to CC anyone who needs to know. It might also be that there's nothing for PNaCl/WASM crew to do. Let's at least determine that one way or the other by M-61?

I'm not going to shut this down by wontfixing, but I have a very hard time seeing this as anything other than reinforcing the argument that you cannot safely write crypto in a language that cannot provide constant execution time guarantees.

That stated, I am dropping this to low-severity, since medium-severity implies a trivial, large scale information leak, such as an arbitrary out-of-bounds read. Whereas even if we assume this to be within the scope of Chrome's threat model, the attack must account for very significant mitigating factors in any real-world scenario.

Strictly speaking, that leaves just assembly, but agreed with the high order bit. :-) At some point when we've solved the rest of the world's problems w.r.t. crypto, I would love for someone to work out a coherent set of constant-time primitives in LLVM...

Though we're not even at worrying about languages yet in that E2E code. Indexing based on secret indices is not constant-time in any language. Crypto code should not do that.

Eran - thanks a lot for your report.

This might be a bug in End-to-End. While e2e doesn't claim to be constant time (because JavaScript), we do intend the algorithms to at the very least be constant time, and it seems we missed it here.

It's a bit weird this is in Chrome's bug tracker, but we can track it here for the time being. I've cc'd the people that are involved on this.

@Chrome, please let us know if you would like to use this bug to discuss the Chrome-specific bits of this, and we'll move the conversation to security@google.com.

Thanks

Eran - do you have any code you can share with us?

We prefer not to share the code, but will be happy to answer your questions.

Meanwhile, as discussed we wish to publish this research. Is there a need for coordinating this with you? Can you assign a CVE number we can include in our publication, so people can track it in the future?

Also, can someone add my coauthors to the bug CC list?
Daniel Genkin <danielg3@cs.technion.ac.il>
Yuval Yarom <yval@cs.adelaide.edu.au>
Lev Pachmanov <levp92@gmail.com>

evn@ - Since this is an e2e issue, I'm closing this bug in our tracker. To the bug reporters, please email security@google.com to continue the conversation (and include a link to this bug for reference).

For those with access, the changes we are making are:
 - cl/163856999
 - cl/163826935
 - cl/162379636

In particular, we are making the following statement in the first CL:
   * Utility function to clone an array of bignums into a new array. This is
   *     necessary because repeated access to the same memory location can be
   *     detected by other websites, which could be used to leak information
   *     about the computations being made across origins.

Is this correct? Any suggestions on how to rephrase the paragraph?

c17, did the mitigations defeat the attack?

we have no idea, the reporter did not provide a PoC.

Any update on the mitigation in the library?
For reference, Mozilla inquired about this paper and would like to coordinate on this an future issues around shared memory + timing attacks.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot