W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2011

Re: Timing attacks against CSS Shaders

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 4 Dec 2011 00:16:17 -0800
Message-ID: <CAJE5ia8BdDVErCo=2jA6PJSNYKunr1eW+GeBMrFiLBspizgc2A@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: public-fx@w3.org, Vincent Hardy <vhardy@adobe.com>, Thomas Roessler <tlr@w3.org>
To avoid repeating the same thread on two mailing lists, the
webkit-dev thread starts here:



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:39 UTC