https://www.evonide.com/side-channel-attacking-browsers-thro
ugh-css3-features/

snip

Bug Discovery

Accessing the DOM of an iframe that includes a cross-origin
resource is forbidden by default. However, the content of
the iframe was displayed in the same context as the rest of
the site so we wanted to verify if there is side-channel
potential that might allow us to leak state information
through the interaction of browser features with the iframed
content. With this in mind, Dario and I went ahead and
tested various CSS features like "transparency", "rotation"
and "mix-blend-mode" on top of the cross-origin iframe.

By doing so, we discovered a bug that allowed side-channel
attacking the CSS feature mix-blend-mode. This feature was
introduced beginning 2016 with CSS3 and is available in
browsers like Firefox and Chrome. Other browsers like
Internet Explorer and Microsoft Edge didn't support the
required feature and Safari didn't seem to be affected. A
full overview of browsers with mix-blend-mode support can be
seen in Mozilla's Developer Network on mix-blend-mode.

After further research, we have discovered that this issue
was already reported to the Chromium team and made
temporarily public by accident through a public Chromium
auto-cc mailing list in March 7th 2017. We reported this
leak and the original thread was made private again.
Finally, the bug was made public in the Chromium bug tracker
on 22.02.2018 and was assigned CVE-2017-15417. We have
delayed the release of this article as it was just recently
fully patched in Firefox 60 so please update your browsers
to the newest versions.
Attack Setup

The discovered side-channel bug allowed to mount the
following attack:

It is possible to overlay the target (cross-origin)
iframe with a stack of DIV elements that have the property
"mix-blend-mode" enabled.
The rendering of this stack can then take a variable
amount of time depending on the underlying pixel color
inside the iframe.
Finally, by moving this DIV "scan" stack across the
iframe, forcing re-renderings and measuring the individual
rendering times it is possible to determine the iframe's
content.

Let's have a look at some real world impact and use cases
before considering more bug details.
Use Cases

An interesting attack potential lies in obtaining
information from websites someone is currently logged into.
In particular, we could mount an attack to read information
served in iframeable content. Fortunately, most sensitive
content like your Facebook message history or your Amazon
order history can't be iframed into other sites that
easily.

In order to protect users from attacks like clickjacking,
mitigations like Javascript iframe busters and later more
solid protections like the HTTP header X-Frame-Options have
been introduced that give users control over which sites are
allowed to iframe specific content.

Nevertheless, the Facebook "login" button shows that there
still exist iframeable endpoints containing personally
identifiable information (PII) you wouldn't want anyone else
to obtain while surfing on other websites.
De-anonymizing Facebook Users

We constructed a proof of concept HTML file containing a
payload for the discovered bug. Opening this file is enough
to load different Facebook endpoints inside iframes and to
start exploitation which can be fully camouflaged as is
demonstrated below.

snip
Posted on: def2.i2p