Re: Timing attacks against CSS Shaders

On Sun, Dec 4, 2011 at 11:35 AM, Ralph Thomas <ralpht@gmail.com> wrote:
> 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.

It's difficult to enumerate all the sources of sensitive information.
It's long been part of the web security model that a web site can
display content and information that it is not allowed to read.

As an obscure example, consider the red wavy lines that many browsers
draw under misspelled words.  Browser's use the user's custom spelling
dictionary to decide whether to draw the wavy line, which often
includes sensitive information like the user's name (if his or her
name isn't in the default spelling dictionary).  We'd need to prevent
these wavy lines from entering a CSS shader to avoid leaking the
user's identity to the web site.

It's very unclearly to me how we'd know we'd blocked all the sensitive inputs.

Adam


> 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:41:51 UTC