Thanks for your report!

Can you actually glean private or sensitive information from another origin, or can you only glean the timing of events (of unknown types) in 1 or more unknown other origins? (There is not not just origin V, but V2, V3, V4, et c., for all the origins a given browser session has open.)

In the demos, I don't see that Chrome leaks meaningful information — although perhaps I am misunderstanding the Youtube demo. Does that demo show the attacker actually reading the keystrokes "hello!", or are those keystrokes visible only to the origin the person explicitly typed them into?

(In general, it's better to attach PoC code to the bug report than to post a video, especially a public video.)

Yes, I only see delays introduced by events, rendering, GPU messages, GC, network requests, etc., potentially produced by an unknown origin. 

However, in the case of sharing the renderer it is possible to know the other origin, and the timing patterns (duration/around/frequency) of events with no JS listener are more or less distinguishable. Each event triggers a different cascade of layout/rendering actions that translates into specific sequences of delays in the message loop.

Also, if an origin V has some JS listener, then the timing pattern (or sequence of delays) will be specific to V and we can learn it previously. Automating this is not easy, since we need some "online learning phase", but I think it is possible.

As for detecting pages in new tabs, the event loops are usually "quiet" when all pages are already loaded (it may depend on the background work), but when a new page is visited a bunch of network requests and rendering tasks are executed, producing a clear pattern (see graph attached) recognizable by the human eye and by classification techniques.

This is what can be seen in the second demo: start monitoring, open new tab, visit page X, stop monitoring. A graphic will be painted with X's loading pattern.

The video was just an example of a covert-channel between 2 cooperative pages from different origins and in different processes. I use timing delays introduced in the I/O thread to transmit the "hello!" message as 0s and 1s. Sorry if I was not clear enough.

Deleted: webfingerprint_traces.png 225 KB

	webfingerprint_traces.png 225 KB View Download

Thank you for providing more feedback. Adding requester "palmer@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

How can origin A (say, attacker.com) reliably know the identity of origin B (say, example.org), due only to the fact that they share a renderer? Origin A would need to have compromised the process (e.g. by exploiting a memory corruption bug), right? If you have some other means of achieving that, I think that would be a bug on its own. Or did you mean just by classifying the event timing patterns?

I'd be somewhat surprised if it were practical for an attacker to classify the event timings of the origin B whose users they want to spy on, for all combinations of origin B state and for all combinations of origin B running together with origins C, D, ... .

+lcamtuf: Potentially of Silence On The Wire interest. It seems to me that some of the attacks described there, such as distinguishing keystrokes by sound (which admittedly is harder for origin A to do, since it would need to request getUserMedia permission), would be easier to achieve in practice. But I could be wrong.

+battre: Do you or someone on Privacy Team want to take this?

Right now two origins share the renderer when: a) using iframes, b) doing a renderer-initiated navigation, or c) the max number of renderers is exceed. An attacker can use a) and b) for knowing the origin of B and spy on it. It's also interesting that when c), all new incognito-tabs share the same renderer.

As an example, an evil advertisment iframed in B has no access to the parent page due to the SOP but may know the origin B thanks to the referer and spy on what the user is doing. Another scenario could be a rogue page that pop-ups Google's OAuth login form and detects the keystrokes:

 http://vwzq.net/lab/messageloop/monitor_goauth.html

This is a very dumb PoC failing a lot, but you can see the idea.

Hi! Just to keep you in the "loop" ;D

Here's a draft of the paper I've been working on: http://vwzq.net/papers/loophole.pdf If you are interested, it contains more detailed info and some experimental results.

Interestingly, the CPU throttling mechanism introduced recently in Chrome broke the test case for spying on the renderer from a background tab (though it can probably be bypassed?), but the rest of the scenarios still work. 

You can now use this http://vwzq.net/lab/loopscan/ to visually inspect the event loops, since the links above are dead. At some point I'll try to add support for the GPU process as well.

Again, any comment/feedback is very appreciated. Thanks.

I still don't see a compelling attack, in the demo or in the paper. For things like detecting what sites the person has browsed or is browsing, there already exist more reliable attacks that don't require resource-intensive statistical characterization. (See e.g. https://diracdeltas.github.io/sniffly/)

I still don't see a keystroke theft attack, which I really would find compelling. Other side channels are more likely to result in that, e.g. microphone and accelerometer, but those sensors are guarded by permissions or other use restrictions.

And there are plenty of other, higher-bandwidth and higher-reliability ways for origins to communicate with each other without the person using the browser knowing.

I'm afraid I just don't see an actionable bug here.

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