W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: Timing attacks against CSS Shaders

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 4 Dec 2011 10:58:21 -0800
Message-ID: <CAGN7qDAHsF_uAk-4hTCY_am9W2df_g2GjRdADD--xYCf0QP76g@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Adam Barth <w3c@adambarth.com>, public-fx@w3.org, Dean Jackson <dino@apple.com>, Vincent Hardy <vhardy@adobe.com>, Thomas Roessler <tlr@w3.org>
Thanks for the link!
The webkit discussion also has some good info.
So, the combination of requestAnimationFrame and changing the duration of a
compositing operation in response to a pixel color, gives you the ability
to harvest information.

Does the browser wait for the GPU to stop compositing or does it upload the
drawing commands and lets the GPU do the compositing asynchronously?


On Sun, Dec 4, 2011 at 10:16 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Sun, Dec 4, 2011 at 10:04 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> > Hi Adam,
> >
> > I don't know much about timing attacks so I have a question.
> > Since the browser directs the GPU to run the shaders and composite their
> > output, the end result is invisible to the attacker since there is no
> > mechanism to get this bitmap data back.
> > The shaders also have no means to communicate through script  since they
> can
> > only manipulate pixels.
> >
> > In this scenario, how would information ever leak?
> > WebGL is different since you have access to the entire OpenGL stack which
> > allows you to do more complex operations such as reading back data.
> The information is read back through the "timing channel", thus the
> name.  This is done by making an operation take more or less time
> based on the information you want to extract, so you can read data out
> just by watching how long an operation took to complete, even if the
> language doesn't offer any way to get the data out normally.
> http://en.wikipedia.org/wiki/Timing_attack
> ~TJ
Received on Sunday, 4 December 2011 18:58:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:39 UTC