[webkit-dev] Timing attacks in rendering, was: Re: Timing attacks on CSS Shaders
Adam Barth
abarth at webkit.org
Thu Dec 8 15:30:38 PST 2011
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
More information about the webkit-dev
mailing list