Re: Update on CSS shaders security issue

2012/4/20 David Sheets <kosmo.zb@gmail.com>:
> On Fri, Apr 20, 2012 at 5:41 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
>> Thanks Vincent for the very nicely written wiki page. I can't see any
>> security flaw in the solution you've arrived at.
>>
>> 2012/4/20 David Sheets <kosmo.zb@gmail.com>:
>>> On Wed, Apr 18, 2012 at 10:54 PM, Vincent Hardy <vhardy@adobe.com> wrote:
>>>> Hello,
>>>>
>>>> Since the original proposal on CSS shaders, there have been discussions on
>>>> this list and some related discussion on the WebGL mailing list at Khronos.
>>>
>>> What is the URL of the discussion on the WebGL mailing list at Khronos?
>>
>> This was on the private '3dweb' mailing list.
>
> Are you making World Wide Web standards or Khronos Members standards?
>
>> https://www.khronos.org/members/login/list_archives/3dweb/1204/msg00059.html
>
> Your discussion medium uses the same web technologies as the World
> Wide Web but inside a paywall...

Hey, everyone agrees that standards must be discussed/decided on
public lists. But we didn't discuss standards there. That was just a
pie-in-the-sky discussion among a few people about the possibily or
impossibility of defeating timing attacks by shading language
limitations. I don't think it was particularly wrong to have that
discussion privately. If you're interested in what we said, the CSS
shaders wiki + my previous email (see below) sum up the conclusions
and key argument.

>
>> In short, we discussed whether restrictions on the shading language
>> could be sufficient to make the use of cross-origin images safe in
>> WebGL and in CSS Shaders, and we agreed that that was unfortunately
>> not the case because even basic arithmetic operations (like
>> multiplication) can take much longer depending on input values (for
>> example on Intel CPUs operations on NaN values can be hundreds of
>> times slower than on finite values).
>
> Unless I am misreading the wiki page, this proposal only applies to
> rendered content textures?
>
> From the wiki:
>
> "Access to other textures from CSS shaders should be considered. The
> security measures should be the same as for WebGL access to textures
> and the same usage of CORS should apply in that context."
>
> Will CORS texture access via texture() be allowed? If both parties consent...
>
>> But all the important conclusions for CSS Shaders are in Vincent's
>> public wiki page.
>
> The wiki page contradicts (and leaves undecided) the issue of
> cross-origin texture access. I understand the need for the rendered
> content texture restriction as the browser security model lacks the
> facility to track taintedness. I do not see an issue with direct CORS
> texture access.
>
> With access to the actual discussions that took place regarding this
> issue, I could probably answer these questions myself by reading with
> my eyes. Unfortunately, a decision was made to keep those discussions
> private without justification. Here are some effects of that decision:
>
> 1. I have to ask you about it and have this meta-discussion on a list
> that should be talking about technical subjects.
> 2. Interested competent peer observers (of which there are thousands)
> are immediately made to be second-class by withholding information
> resulting in..
> 3. Social and technical domination by the entrenched parties through
> enforced ignorance on the public which leads to...
> 4. Resentment and a discouragement of cooperation resulting in...
> 5. Weaker standards and more work for you.
>
> I think the FXTF and WebGL WG have been doing important work that will
> sit at the foundation of hypermedia for decades should their standards
> find adoption and provide means for evolution. Withholding important
> general technical discussion from the public forum does not encourage
> adoption or safeguard against evolutionary stagnation.
>
> The Web is bigger than any collection of us,
>
> David Sheets
>
>>>> Following the most recent findings in efforts to make CSS shaders secure, I
>>>> have updated the page that summarizes the proposed security measure that
>>>> looks the most reasonable. The other measures that were considered are also
>>>> documented and a summary of why there did not fully meet the needs is also
>>>> provided.
>>>>
>>>> The short description of the proposal is that it removes access to the
>>>> rendered content from the shaders. This is not an issue for vertex shaders
>>>> (at least for a wide set of use cases). For fragment shaders, the result
>>>> produced by the shader will be combined with the rendered content, but this
>>>> combination step is not controlled by the shader, it is controlled by the
>>>> implementation.
>>>>
>>>> For example, a vertex shader that produces a flapping flag effect will not
>>>> be affected by the restriction because it does not need access to the
>>>> texture. A fragment shader that computes a lighting effect will compute a
>>>> light map that the implementation will then multiply with the original
>>>> texture. Here again, the shader does not access the rendered texture.
>>>>
>>>> I believe that this is a good approach and while it reduces some of the
>>>> functionally, it also addresses the new security concerns CSS shaders
>>>> raised.
>>>>
>>>> Please see the detailed description of the approach and examples of how a
>>>> technology like ANGLE could be used for an efficient implementation:
>>>>
>>>> http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
>>>>
>>>> Kind regards,
>>>> Vincent Hardy
>>>
>>>

Received on Sunday, 22 April 2012 13:07:18 UTC