Re: Timing attacks against CSS Shaders

Until there is a strategy on preventing timing leaks, is there a way
you could change the content being shaded to not include sensitive
information (no external iframes, no :visited on links going to other
domains, no external-domain images [or none that needed
cookies/auth/etc to fetch])? Kind of like XHR is careful not to fetch
things it shouldn't.

Ralph

On Sun, Dec 4, 2011 at 11:07 AM, Adam Barth <w3c@adambarth.com> wrote:
> 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:35:51 UTC