Re: Timing attacks against CSS Shaders

To avoid repeating the same thread on two mailing lists, the
webkit-dev thread starts here:

https://lists.webkit.org/pipermail/webkit-dev/2011-December/018762.html

Adam


On Sat, Dec 3, 2011 at 11:38 PM, Dean Jackson <dino@apple.com> wrote:
>
> On 04/12/2011, at 6:23 PM, Adam Barth wrote:
>
>> I spent some time looking at CSS Shaders, and they seem to suffer from
>> a serious timing attack.  The details are described in this blog post,
>> which I've reproduced (in part) below:
>>
>> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html
>
> I emailed a response on the webkit list, but I'll include it here too.
>
> 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
>

Received on Sunday, 4 December 2011 08:17:18 UTC