Re: Update on CSS shaders security issue

Hi Chris,

Thanks for your feedback and I think it is good to have these discussions. I hope you won't mind the top-reply, as I am trying to organize things to clarify my answer. I am organizing it around the points you bring up and I hope I did not miss anything. Let me preface this by saying that I would much prefer not having the restriction I proposed, but at this point, I think this is the right way to proceed.

Unproven attacks?

The write-up at http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security discusses different types of security concerns. However, in all cases, the issues boils down to a) having access to sensitive data (either third party data as in your iframe example or user agent data such as visited links) and b) having a 'communication channel' which allows the shader to send data to an accomplice script.

We have been able to demonstrate internally that a visited link attach was possible. Essentially, the technique is the same as was demonstrated on WebGL shaders before. It is not hard to implement. That demonstration convinced our team that the threat is real and we cannot allow shaders to vary their execution time in a detectable way.

Are shaders still useful with the proposed restrictions?

I respectfully disagree with the point that the restriction nullifies the usefulness of CSS shaders. Here is why:

1) vertex shaders are extremely useful even without texture access. They do not need a very dense mesh. Most of the examples we created have excellent visual results with modest size meshes (20x20 to 50x50). Compared to the number of pixels fragment shaders process, this is low density. All kinds of very nice effects can be achieved with this. Actually, I think this is a the part of CSS shaders that we should strive to make most progress on quickly, because there is no good fallback solution for what it offers.

2) fragment shaders are, I agree, restricted quite severely with this proposal. However, there are two important points to make:
- filters that apply a uniform operation on an image do not require a shader. Granted, shader may often do multiple things in combination and that is useful / efficient, but the functionality is not fully gone. There are SVG filter graphs and there are filter shorthands.
- we could extend the definition of what fragment shaders can do. For example, Alex internally has been suggesting that the restricted fragment shaders could produce a convolution matrix which the implementation would then use to produce the fragment color input to the shader. That is an alternate way of writing the shader and defining the restriction. My point is that we can work on the fragment shader restrictions if we find the current one is too limiting. But even then, and again looking at all the examples we have come up with, I think there is a lot of very useful things we can do (light maps being one important one).

Could we ever remove the proposed restriction?

We have worked hard internally at Adobe on a solution to the timing attacks that we had been able to reproduce. We were successful in deflecting that particular attack. See the work suggested by Gregg that Max and Alex did at:

http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security#Method_H:_Tainting_shader_code_branches
http://code.google.com/p/mvujovic/wiki/ShaderControlFlowAnalysis

However, this does not protect against attacks that would exploit the varying execution time of floating points as was raised recently and is a known performance issue (see http://en.wikipedia.org/wiki/Denormal_number#Performance_issues).

Our current approach at Adobe is to first implement shaders with the restrictions because we think this is a) still a huge step forward (especially because it brings in vertex shaders) and b) a relatively low hanging fruit to implement. Once we have that in, we are planning on actually testing out the performance issues with floating point operations. Hopefully, we can gather evidence that the threat is not valid, but that will take time and research.

The discussions I have had with people who know a lot more than me on this topic is that the floating point units on CPUs are known to take slow paths in some conditions and if a shader implementation was to use these floating point units, an attack would be easy. However, in a lot of cases, it seems that floating point computations are moving to SSE (on Intel architectures, http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions) and I do not know how bad the problem is there. We need to do a lot of research to see if the security restriction can be lifted: we need to understand more about the software fallbacks and do more testing on different CPU and GPU architectures.

I should note that we did run several experiments on GPUs (while working on control flow analysis) and so far, we have not been able to see detectable execution times on arithmetic operations. But more research is needed to have a definite position. In the meanwhile, imposing restrictions allow us to proceed.

Relation to CORS

You point out that we should look at restricting shading third party content instead of restricting access to pixel values. Unfortunately, this does not solve the problem of access to user agent data (visited links). This is why we have focused on restricting access to pixel values and/or removing the ability to communicate from the shaders.

Should we move to a different approach?

Your email suggest that may be we should move to fixed function shaders. For fragment shaders, that may be a good solution, but I am not clear how this would be essentially different from the filter graphs SVG filters already provide. For vertex shaders, I think we definitely need to keep the functionality and approach we have taken.

I hope this clarifies our approach,
Kind regards,
Vincent

On Apr 21, 2012, at 8:02 AM, Chris Marrin wrote:


I just wanted to toss my 2 cents in here. First let me say that while I'm still editor of the WebGL spec, I'm no longer in the WebKit group. So my observations about CSS shaders are as an interested 3rd party. And let me also say that I have great respect for all the work this group has done.

If I am reading your proposal right you're saying that we will have no access to the texture we're filtering in the shaders. If so, that would seem to nullify the usefulness of this feature. The two examples you give (vertex shader-based image warping and fragment shader "lighting") are really the only two effects that would be practical. Vertex shader warping is mildly interesting, but will need very dense meshes to get really interesting effects. But you're really only allowing fragment shaders to be image generators which are then blended with the source image. That doesn't seem interesting at all. With this restriction you lose out on any fragment shader based image warping, blurring, and almost all interesting (IMHO) use cases.

That leads me to ask, is it worth it? Maybe the energies of this group would be better spent focusing on more advanced fixed function shaders. For instance, adding the majority of the CoreImage filters and the ability to combine filters with a graph topology would at least give you access to a wide variety of advanced filtering techniques.

Moving down this path takes away an incredibly powerful tool from web authors. Another implication is that WebGL will never be able to access rendered page content, cutting out many interesting and powerful effects, which have already been demoed. It is, in effect, stifling advancement of the web platform due to non-technical privacy concerns.

On several occasions I've brought up the point that all these concerns are based on unproven attack vectors. That point has been repeatedly shot down with claims that it has been proven, referencing some vague numbers that show it's possible for a shader to take different amounts of time based on a pixel's color. All that might be true, but never have I seen an actual example of an attack. Where is the site I can go to where I can type a string into a text box and within a few seconds the site tells me what I typed merely by examining the image of what I typed? Maybe such a thing is possible, but it seems wrong to cut out a powerful feature like this before proving it. Once it is proven, some browser vendor might come up with a technique to thwart such an attack. Then it becomes an arms race between clever attackers and clever defenses. But isn't that what the web has been all about for many years?

And maybe this group, rather than looking at ways to make it impossible to deduct the value of pixels from a shader, should instead look at making it impossible for an attacker to get at the pixels of a legitimate site in the first place. Would preventing frame based content from running shaders solve that problem? I don't know, but it seems like its important to understand how an attack would work end-to-end and then stop it somewhere other than in the fragment shader.

I understand that these points probably won't be any more well received now than they have in the past. But I felt the need to say them. This really is the future of the web. If these problems can't be solved now, it doesn't bode well for things to come.

On Apr 18, 2012, at 10:54 PM, Vincent Hardy 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.

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

-----
~Chris
cmarrin@apple.com<mailto:cmarrin@apple.com>