[webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)

[Dean Jackson]

On 25/10/2011, at 3:13 AM, Dirk Schulze wrote:

>>> I'd like to know what the actual threat of such timing attacks are. I've seen claims of a maximum theoretical leak rate (in bits/s) but then counter claims that since, in this case, it would be hard to distinguish the difference in slowdown between CSS shaders and general page rendering, that the real rate is much lower. And, at least in the case of Safari, you can't always be sure that getting a rAF callback means you're about to draw.
>>> 
>>> Does anyone have hard data on this?
>> 
>> At a minimum, please do not land an implementation for this feature
>> without a way for ports that are concerned about this security feature
>> to disable it independently of both CSS_FILTERS and WEBGL.  Contrary
>> to your previous assertion, the security implications are quite
>> different than those with WebGL.

Sorry, I was assuming a WebGL that allowed input from canvasContext.drawElement. At that point I think they are close enough to call the same (no doubt I'm wrong! :) Even without drawElement, WebGL offers a lot of attack vectors.

> We already discussed the HW acceleration of SVG Filters on https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS Filters earlier on this mailing list. We agreed that we will continue to use the implemented software rendering as fallback for Filters. CSS Shaders won't be included. Shaders should just be supported if HW acceleration is enabled. And I think as a minimum consensus on bug 70099 most people on the thread agreed to go on with GraphicsContext3D for now. In my opinion it means we would have the same security concerns like on WebGL. That's also one reason why I think that the WEBGL flag would match these needs quite well, even if CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS Shaders are deactivated (and ignored if web developers use them in their filter chain) and Filters take the software rendering fallback.

Adam's point in the bug is that any operation that can access colour channels might be able to perform a timing attack. This would include SVG filters operating on HTML content without any hardware acceleration.

For this reason I'm still tempted to suggest the combination of CSS_FILTERS + WEBGL is enough of a switch for ports to disable this, but I'm happy to add another one.

I'm not sure at what point we should take the discussion from this list and onto bugzilla.

Dean