[webkit-dev] Timing attacks in rendering, was: Re: Timing attacks on CSS Shaders

[Charles Pritchard]

On 12/3/11 11:37 PM, Dean Jackson 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.
>> 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. 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).
>
...
> Is there something we can do to make rendering-based timing attacks
> less feasible?
>
...
> Or maybe rAF is inherently insecure?

Is there an active interest in investigating these issues? I understand 
that CSS Shaders is bringing them to the forefront.

I am confident we can move Shaders forward in a limited and safe manner, 
by starting first on CORS Media elements, essentially bringing them to 
parity with WebGL Canvas.

That is to say: <canvas></canvas> -- with WebGL is up on the web and 
tested as a means to apply filters to <img> and <video>.
Surely we can provide a CSS short-cut.

But back to my concern: Sometimes a new idea or use case brings up real 
engineering issues that get pushed-back as people push-back on the use 
case or broader implications. I experienced that phenomenon to a large 
degree with the <canvas> tag in Canvas 2d. I'd like to do better with 
pixel shaders.

Is there an objection to CSS Shaders for media elements, origin safe 
video, img and canvas? They work in WebGL, they should work fine in CSS.

Is there reasonable support for investigating timing issues inside of 
the browser? We have baseline issues from latency in network requests: 
If I request an image from a site you've already visited, it's likely to 
load quicker than a subsequent request for a random 404 page from that 
site. I feel that this baseline issues can help us take some of the 
controversy away from future studies on timing issues. They already 
exist, they're accepted and acceptable for consumer-grade browsers.

I'm getting the feeling that these very interesting and important cases 
brought up by Dean Jackson, are not being evaluated.
Webkit vendors, and many w3c vendors, should have an interest in seeing 
them analyzed.

So I'm reaching out here and saying, does anyone think this is a 
worthwhile avenue for serious study? Is it simply not important for this 
generation of browsers?

Though webkit has a bias against "scientific experiment" on the code 
base, being that it's an "engineering" project, it seems to me like 
engineering and science as well as security and quality, benefit from 
asking these questions and doing focused research.


-Charles