- From: Adam Barth <w3c@adambarth.com>
- Date: Sun, 4 Dec 2011 00:16:17 -0800
- 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: 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