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

[Chris Marrin]

On Dec 3, 2011, at 11:57 PM, Adam Barth wrote:

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

To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. And I've never seen a renderer that runs "1000x slower" when rendering a pixel with transparency. It may runs a few times slower, and maybe even 10x slower. But that's about it.

I'm still waiting to see an actual "compelling" attack. The one you mention here:

	http://www.contextis.co.uk/resources/blog/webgl/poc/index.html

has never seemed very compelling to me. At the default "medium" quality setting the image still takes over a minute to be generated and it's barely recognizable. You can't read the text in the image or even really tell what the image is unless you had the reference next to it. For something big, like the WebGL logo, you can see the shape. But that's because it's a lot of big solid color. And of course the demo only captures black and white, so none of the colors in an image come through. If you turn it to its highest quality mode you can make out the blocks of text, but that takes well over 15 minutes to generate.

And this exploit is using WebGL, where the author has a huge amount of control over the rendering. CSS Shaders (and other types of rendering on the page) give you much less control over when rendering occurs so it makes it much more difficult to time the operations. I stand behind the statement, "... it seems difficult to mount such an attack with CSS shaders because the means to measure the time taken by a cross-domain shader are limited.", which you dismissed as dubious in your missive. With WebGL you can render a single triangle, wait for it to finish, and time it. Even if you tuned a CSS attack to a given browser whose rendering behavior you understand, it would take many frame times to determine the value of a single pixel and even then I think the accuracy and repeatability would be very low. I'm happy to be proven wrong about this, but I've never seen a convincing demo of any CSS rendering exploit.

This all begs the question. What is an "exploit"? If I can reproduce with 90% accuracy a 100x100 block of RGB pixels in 2 seconds, then I think we'd all agree that we have a pretty severe exploit. But what if I can determine the color of a single pixel on the page with 50% accuracy in 30 seconds. Is that an exploit? Some would say yes, because that can give back information (half the time) about visited links. If that's the case, then our solution is very different than in the first case. 

I think we need to agree on the problem we're trying to solve and then prove that the problem actually exists before trying to solve it. In fact, I think that's a general rule I live my life by :-)

-----
~Chris
cmarrin at apple.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20111205/5c68c3c7/attachment.html>