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

[Dean Jackson]

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. 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).

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. 

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?

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.

Or maybe rAF is inherently insecure?

Dean



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