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

[Charles Pritchard]

http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0227.html
I appreciate the redirect, and the comments on this thread.

I've taken this to FX, specifically about rendering. FX previously 
discussed what amounts to a11y issues on the CSS Shaders proposal.

I intend to take the topic to webapps as well, given the variety and 
ease of use of various non-rendering timing tricks.

I'm feeling quite confident that CSS Shaders will move forward, though 
slowly, toward reproduction of the proof of concept.

-Charles


On 12/8/11 3:30 PM, Adam Barth wrote:
> Your message is somewhat off-topic for this mailing list, which is
> about the development of the WebKit engine.  Would you be willing to
> re-send your message to the FX task force:
>
> http://www.w3.org/Graphics/fx/
>
> That's the appropriate venue to discuss use cases and the like for CSS
> Shaders.  That way we can get feedback from a variety of implementors
> instead of just WebKit.
>
> Adam
>
>
> On Thu, Dec 8, 2011 at 1:51 PM, Charles Pritchard<chuck at jumis.com>  wrote:
>> 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
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev