[webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

[Adam Barth]

On a personal note, Dean, please don't feel like I'm singling you
or your colleagues out.  More or less this exact feature request has
come up internally within Google at least three separate times.
I'm telling you now exactly what I told those folks then.  (Although I
did do some more research this time to make sure I had my ducks in a
row.)

I would very much like for this feature to succeed.  The demos of
what you can build with this feature are really impressive.  I'm sorry
that I don't know how to make it secure.

Adam


On Sat, Dec 3, 2011 at 11:57 PM, Adam Barth <abarth at webkit.org> wrote:
> On Sat, Dec 3, 2011 at 11:37 PM, Dean Jackson <dino at apple.com> wrote:
>> On 04/12/2011, at 6:06 PM, Adam Barth wrote:
>>> On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth <abarth at webkit.org> wrote:
>>>> Personally, I don't believe it's possible to implement this feature
>>>> securely, at least not using the approach prototyped by Adobe.
>>>> However, I would love to be proven wrong because this is certainly a
>>>> powerful primitive with many use cases.
>>>
>>> I spent some more time looking into timing attacks on CSS Shaders.  I
>>> haven't created a proof-of-concept exploit, but I believe the current
>>> design is vulnerable to timing attacks.  I've written up blog post
>>> explaining the issue:
>>>
>>> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html
>>
>> Thanks for writing this up.
>>
>> I'm still interested to know what the potential rate of data leakage is.
>> Like I mentioned before, there are plenty of existing techniques that could
>> expose information to a timing attack. For example, SVG Filters can
>> manipulate the color channels of cross-domain images, and using CSS overflow
>> on an iframe could potentially detect rendering slowdowns as particular
>> colors/elements/images come into view.
>
> My understanding is that shader languages allow several orders of
> magnitude greater differences in rendering times than these
> approaches.  However, as I wrote in the post, I don't have a
> proof-of-concept, so I cannot give you exact figures.
>
>> CSS shaders increase the rate of leakage
>> because they execute fast and can be tweaked to exaggerate the timing, but
>> one could imagine that the GPU renderers now being used in many of WebKit's ports
>> could be exploited in the same manner (e.g. discover a CSS "trick" that drops
>> the renderer into software mode).
>
> I don't understand how those attacks would work without shaders.  Can
> you explain in more detail?  Specifically, how would an attacker
> extract the user's identity from a Facebook Like button?
>
> In the CSS Shader scenario, I can write a shader that runs 1000x
> slower on a black pixel than one a white pixel, which means I can
> extract the text that accompanies the Like button.  Once I have the
> text, I'm sure you'd agree I'd have little trouble identifying the
> user.
>
>> Obviously at a minimum we'll need to be careful about cross-domain content,
>> and give input to filters (not just CSS shaders, and moz-element or ctx2d.drawElement)
>> that doesn't expose user info like history.
>
> As discussed in Bug 69044, I do not believe the blacklisting approach
> will lead to security.
>
>> But I wonder if there is also some more general approach to take here.
>> You mention Mozilla's paint events and requestAnimationFrame. Without those
>> it would be much more difficult to get timing information. The original
>> exploit on WebGL was especially easy because you could explicitly time a
>> drawing operation. This is more difficult with CSS (and in Safari, we
>> don't necessarily draw on the same thread, so even rAF data might not
>> be accurate enough).
>>
>> Is there something we can do to make rendering-based timing attacks
>> less feasible?
>
> As discussed in the blog post, once the sensitive data has entered the
> timing channel, it is extremely difficult to prevent the attacker from
> observing it.  Preventing the sensitive data from entering the timing
> channel in the first place is the most likely approach to security.
>
>> Here's a idea I heard floated internally: since the rAF-based attack would be
>> trying to trigger cases where the framerate drops from 60fps to 30fps, is
>> there some way we can detect this and do something about it? For example,
>> once you drop, don't return to 60fps for some random amount of time even if
>> it is possible. This might sound annoying to developers, but I expect anyone
>> legitimately concerned with framerate is going to want to do what they can
>> to keep at the higher value (i.e. they'll want to rewrite their code to
>> avoid the stutter). This doesn't stop the leak, but it slows it down. And as
>> far as I can tell everything is leaky - we're just concerned about the
>> rate. I know there won't be a single solution to everything.
>
> Approaches analogous to those have been tried, unsuccessfully, in many
> settings since the mid seventies.  In fact, I'm not aware of any cases
> where they were successful.  It's possible that this setting is
> different from all those other settings, of course, but I'm dubious.
>
>> Or maybe rAF is inherently insecure?
>
> I don't know what "inherently" insecure means.  I don't believe
> removing requestAnimationFrame from the platform would be sufficient
> to make adding CSS Shaders secure, if that's what you mean.
>
> Adam
>
>
>>> Jonas Sicking seems to have a similar concern:
>>>
>>> https://twitter.com/#!/SickingJ/status/143161375823380480
>>>
>>> It's probably worth addressing this concern sooner rather than later.
>>> Ignoring it certainly won't cause the vulnerability to go away.
>>>
>>> Adam
>>