Re: [filter-effects] shader security model

I am sorry. This mail was supposed to get to www-style, because it was part of the CSS WG discussion today.

+CC www-style as informative reference with preserved mail history. Discussions should continue on public-fx. Thanks David.

On Mar 6, 2013, at 11:00 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> 
> On Mar 6, 2013, at 10:44 AM, L. David Baron <dbaron@dbaron.org> wrote:
> 
>> [ +public-fx ]
>> 
>> On Wednesday 2013-03-06 10:22 -0800, Dirk Schulze wrote:
>>> During the conference call today issues were raised about security problems with shaders. I would like to summarize the security discussions that we had so far and explain how we addressed these issues. For the complete discussion take a look at [1].
>> 
>> I probably shouldn't have concentrated as much on the security
>> issue; my broader point is that the shaders part of the
>> specification has less consensus than the rest of the specification,
>> and is far more in an experimental state, and should thus be in a
>> separate document.
> 
> Thanks for your reply David. There are still a lot of things that we need to resolve on the other filter primitives for Filter Effects and that will take some time. I am less concerned about possible open issues on shaders at this point. Some of the issues on the initial Filter Effect draft are:
> 
> - unbound filter regions
> - stdDeviation values on feGaussianBlur and feDropShadow
> - subregions clipping input or output of a primitive
> - child | child-selector
> - clarifications on premultiplied to non-premultiplied input
> - clarifications on color-interpolation-filters
> 
> (and partly have been on the FXTF agenda for the last call).
> 
> I wanted to resolve on a new working draft not only because of the changes to custom filters, but more because of a lot of clarifications for the other filter primitives and shorthand filters. At this point I do not see shaders blocking the standardization process of the whole spec. Should people still be concerned about the implementation status of shaders later in the process, we can put shaders on the risk list before going to CR. It may go into the next level of Filter Effects at this point.
> 
> Do you disagree with this strategy?
> 
> Greetings,
> Dirk
> 
> 
>> 
>> -David
>> 
>> -- 
>> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
>> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂

>>> Hi,
>>> 
>>> During the conference call today issues were raised about security problems with shaders. I would like to summarize the security discussions that we had so far and explain how we addressed these issues. For the complete discussion take a look at [1].
>>> 
>>> Security experts like Adam Barth found possible timing attacks with the initial CSS Shaders proposal submitted to the CSS WG more than a year ago.
>>> 
>>> Initial proposal:
>>> ============
>>> - Shaders had direct access to rendered web content. Therefore, the shader had information about visited links and similar secure data. Also, the rendered content possibly came from a different domain than the shader. 
>>> - If shaders could communicate to attackers, this data could be leaked. This could be achieved by timing attacks with fragment shaders.
>>> - Fragment shaders were allowed to access pixel data of rendered content. Fragment shaders could be written in a way to run slower or faster based on the color value of pixels. With functions like requestAnimationFrame, this difference could be measured.
>>> 
>>> How did the Filter Effects WD address these issues?
>>> ========================================
>>> - Fragment shaders do not have direct access to pixel data of rendered web content. To still provide the basic functionality of fragment shaders, it is possible for the author to generate color values independent of the rendered web content and use blending functions to blend the generated color with the rendered web content.
>>> - Shaders referenced in SVG Filters can use results of previous filter primitives as primary input. These results are treated as rendered web content and fall under the same restrictions as other rendered web content.
>>> - Shaders referenced in SVG Filters can use results of previous filter primitives as secondary inputs (via texture parameters). If the results of the primitives are a direct or indirect result of rendered web content, the shader is not executed and acts as a pass through filter. This is because shaders are allowed to sample the colors of texture parameters, unlike the primary input[].
>>> 
>>> The current model is very restrictive and was proposed to the working groups and other security experts. There is no known attack pattern on the current model.
>>> 
>>> Greetings,
>>> Dirk
>>> 
>>> [1] http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security

>>> [2] http://www.w3.org/TR/filter-effects/#feCustomElement

Received on Wednesday, 6 March 2013 19:15:34 UTC