Insecure context might be able to gain timer from Securer context
Closed this issue · 5 comments
Securer context will be able to gain high-precision timers. The way Securer context prevent abuse of such timer is currently focused on only loading opt-in resources inside Securer context (process).
However, I do not see anything in the doc that's preventing same-origin communication between Insecure context and Securer context. For example, BroadcastChannel or SharedWorker can be used to build communication channel between Insecure context and Securer context (at least in Chromium, because those are built using IPC).
Once communication channel has been set up, Insecure context can ask for current timestamp (in whatever form) from Securer context.
Any thoughts on this?
The secure context spec generally breaks the link between "secure enough" SharedWorker instances. See https://www.w3.org/TR/secure-contexts/#example-2829bc67 and https://www.w3.org/TR/secure-contexts/#monkey-patching-shared-workers. Presumably we'd update that to include these types of secureness as well.
BroadcastChannel is more of a risk, called out in https://www.w3.org/TR/secure-contexts/#isolation. With regard to timing, I'm not sure it's much of a risk, given the noise generated via the latency involved in routing messages cross-process.
(Note that COOP should prevent two same-origin pages from obtaining references to each other if they aren't both covered by the same COOP rule, and therefore allows browsers to put them into distinct processes. I think we can reasonably assume that boundary will exist.)
With regard to timing, I'm not sure it's much of a risk, given the noise generated via the latency involved in routing messages cross-process.
Yes, I agree to this. Hopefully, latency varies every time so that attack would not work.
Great. I'll mark this as a documentation bug to make sure we incorporate it into the security considerations section of whatever spec we end up writing.
I'm archiving this repo. I'm not entirely sure where I'd direct you for this issue. Perhaps https://www.w3.org/TR/post-spectre-webdev/?