Re: Update on CSS shaders security issue

Hi David,

I agree with your concerns about having the discussions happen on the appropriate forums and this is why as soon as the discussion moved to CSS shaders, it was moved to the public-fx mailing list. For the record, the discussion on the WebGL mailing list started with an open question about whether the CSS shaders Method H could apply to WebGL shaders under some circumstances. The discussion then brought up new issues for CSS shaders which were immediately brought up to this mailing list. Here is the exerpt from the email I sent to the web3d mailing list:

====
Hi Benoit, all,

While the work we did on analyzing shaders and detecting 'tainted' branches was promising (http://code.google.com/p/mvujovic/wiki/ShaderControlFlowAnalysis), we are now convinced that it will be insufficient for the reasons you pointed out.

I have just posted a proposal to the public-fx mailing list to describe how we believe we should proceed:

http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0010.html

this is documented at:

http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security

Since this is a CSS shaders issue, I would appreciate if you could post your comments / responses to the public-fx mailing list.

Kind regards,
Vincent Hardy
======

As Benoit said, what was done is summarize and explain the concerns that were raised on the public wiki and then bring it to the public-fx mailing list.

Regarding the usage of CORS, the proposal is to disallow texture access only for the rendered content. Other textures can be accessed subject to CORS. This is detailed in the following section of the proposal:

http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Access_to_other_textures

Kind regards,
Vincent

From: Benoit Jacob <jacob.benoit.1@gmail.com<mailto:jacob.benoit.1@gmail.com>>
Date: Fri, 20 Apr 2012 14:35:43 -0700
To: David Sheets <kosmo.zb@gmail.com<mailto:kosmo.zb@gmail.com>>
Cc: Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>, "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Subject: Re: Update on CSS shaders security issue

2012/4/20 David Sheets <kosmo.zb@gmail.com<mailto:kosmo.zb@gmail.com>>:
On Fri, Apr 20, 2012 at 5:41 AM, Benoit Jacob <jacob.benoit.1@gmail.com<mailto: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<mailto:kosmo.zb@gmail.com>>:
On Wed, Apr 18, 2012 at 10:54 PM, Vincent Hardy <vhardy@adobe.com<mailto: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