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

[Adam Barth]

On Tue, Oct 25, 2011 at 3:14 AM, Dirk Schulze <krit at webkit.org> wrote:
> Am 24.10.2011 um 21:51 schrieb Adam Barth:
>>> 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.
>
> 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.

I don't believe that's correct.  The issue I described above arises
only when we run shaders authored by the web site on content rendered
by WebCore.  Can you explain how to conduct the attacks I'm worried
about using HW accelerated SVG Filters or 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.

I'll repeat what I wrote before (edited for grammar):

----8<----
At a minimum, please do not land an implementation of this feature
without a way for ports that are concerned about this security issue
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.
---->8----

If you'd like to experiment with this feature, I have no desire to
prevent you from doing that.  I'm just asking that you not force other
ports to ship security vulnerabilities to their customers.

I'd also recommend that you do a security review of this feature--with
this concern in mind---because I'm fairly confident you'll find that
you'll need to redesign the API significantly before other browser
vendors will be willing to implement it.

On Tue, Oct 25, 2011 at 8:43 AM, Dean Jackson <dino at apple.com> wrote:
> 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.

That might or might not be true, but it doesn't offer *this* attack
vector.  Security is a multidimensional property, hence the "vector"
terminology.  For various reasons, a number of browser vendors have
decided to accept whatever risks implementing WebGL poses.  They have
not, however, decided whether to accept the different risks posed by
CSS shaders.  I'm just asking for the ability to make that decision
myself.

On Tue, Oct 25, 2011 at 8:43 AM, Dean Jackson <dino at apple.com> wrote:
> 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.

I don't believe you understand the security issue.  I'd recommend you
seek the advice of security experts to help you make this decision.

Adam