Re: Timing attacks against CSS Shaders

On Sun, Dec 4, 2011 at 10:51 AM, Ralph Thomas <ralpht@gmail.com>
wrote:
> Would it be possible to disable CSS shaders on a page which uses them
> and takes too long to composite? The goal of CSS shaders is visually
> rich _interactive_ experiences, so you could probably make the
> threshold low enough (100ms?) that timing attacks would be much harder
> -- especially if rAF is rounded to the vblank interval... Depending on
> where rendering takes place, the attacker might still have one full
> iteration of the slow shader to measure though.

Generally, approaches like that have been tried in many other settings
to stop or slow leaks in the timing channel.  They've generally been
unsuccessful in those settings, but that doesn't mean they'll
necessarily be in successful in our setting.

The problem with these sorts of approaches is it's difficult to
actually stop the information leak.  You can only slow it down.  For
example, if you requires the page to render at some fixed frame rate,
what happens when the page takes too long to render?  You'll end up
doing something different, and that difference is likely observable to
the attacker, leaking one bit of data.  It doesn't take very many bits
of data before the attacker can extract text, for example, in a
cross-origin iframe.  In some case, for example history sniffing, the
attacker is only looking for one bit: did the user visit my
competitor's web site.

On Sun, Dec 4, 2011 at 10:58 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> 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.

I wouldn't focus too much on requestAnimationFrame.  Once the
sensitive data is in the timing channel, it's likely to be observable
via other mechanisms.

> 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?

It doesn't really matter.  Even if all the drawing takes place
asynchronously, at some point the pipeline will be full, which is
likely observable to the attacker as a dropped frame.  Another way to
think about this is if the attacker can "keep the GPU busy", then he
or she might be able to observe that WebGL operations take longer.

Adam


> 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 19:09:04 UTC