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

[Adam Barth]

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
>