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<ch...@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<aba...@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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
