Event loops/Message pumps security issues

[gterzian]

Just some sharing of this paper: https://arxiv.org/abs/1702.06764 "Loophole: Timing Attacks on Shared Event Loops in Chrome".

What I find particularly interesting is that, besides the 'script event-loop' sharing attacks they perform(which are only possible when browsing context would actually share a script-thread/event-loop, which in Servo seems to be more restrictive than in Chrome), they also describe attacks that use other 'event-loops/message pumps' running outside of the script event-loop.

This second type of attack could be relevant for Servo, because obviously we have a lot of those message pumps that perhaps could indeed be 'timed' from JS code executed in a script thread.

For example:

1. Constellation's run would qualify as such an event-loop, that indeed, because it handles messages from script, could perhaps be timed from JS code.
2. The embedder's loop. In fact, we've started sending messages directly from script to the embedder, bypassing the Constellation's loop(see Embedder handling of prompts and alerts #20707) (the embedder messages are forwarded via the constellation's loop).
3. Perhaps something like net's wait_for_response used in Fetch.

The threat model could look a bit like:

1. JS code doing something that results in a FromScriptMsg being handled by the constellation in some way that is noticeable and timeable by that same JS code.
2. Which would enable the JS code to find out other stuff going on in the constellation's handling of other messages, such as messages from other script-threads, whether isolated in their own process or not, and also messages from compositor, which includes keystrokes(so an attacker in a tab that is not focused, could for example guess the keystrokes meant for the tab that is by timing the iteration of the constellation's loop).

Worth being aware of, I guess...

[gterzian]

One possible solution, not mentioned in the paper, would be to make each iteration of the constellation loop take constant time. Obviously it would make each iteration as slow as the slowest possible one(except something like shutdown I guess), which might not be acceptable, but it would certainly prevent any sort of timing.
Perhaps this could be done in a fairly granular way so as to only affect handling messages coming from script, for example by only making handle_request_from_script execute at constant time, or in an even more granular way by doing this only for certain messages that would offer the greatest opportunity for timing via something observable in the JS code(Obviously, 'something observable from JS code' could arise from non-script messages too).

[jdm]

cc @avadacatavra so you're aware of this research