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

[Adam Barth]

On Mon, Oct 24, 2011 at 9:38 PM, Dean Jackson <dino at apple.com> wrote:
> On 24/10/2011, at 9:08 PM, Adam Barth wrote:
>> How have you solved the security problems with CSS Shaders?
>> Specifically, timing attacks can be used to extract image information
>> passed to shaders and many things WebKit renders are sensitive and
>> should not be exposed to the web site (e.g., the color of visited
>> links).
>
> This is a good question and I know that I don't have the answers (and can't even claim to understand all the implications).
>
> I think the most important restriction is that shaders should not apply cross-origin. e.g. iframes and probably anything with <img> children from another domain (unless it is marked as ok via CORS).

There's an issue even with same-origin content.  The issues are quite
similar to the security issues with canvas.drawElement.  Please see
the extensive discussion on
https://bugs.webkit.org/show_bug.cgi?id=69044.

> The possibility of leaking information such as visited links, or maybe reconstructing text which could be fed to OCR, is more difficult. Is this really specific to CSS Shaders? SVG filters would theoretically be able to do the same thing. In fact, given enough knowledge of WebKit rendering one could imagine tweaking the style of an element in a way that causes a measurable rendering slowdown.

If that were true, it would be a serious privacy attack.  We've taken
care that a web site cannot learn about which links the user has
visited, even with tricky timing attacks.  For example, visited and
non-visited links cannot have styles that differ in the alpha channel
because differences in the alpha channel show up as differences in
rendering time.

> 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.

Personally, I don't believe it's possible to implement this feature
securely, at least not using the approach prototyped by Adobe.
However, I would love to be proven wrong because this is certainly a
powerful primitive with many use cases.

Adam