Re: tainting in CSS custom filters: texture indirection as a timing attack?

On Jun 19, 2012, at 11:49 AM, Stephen White wrote:



On Tue, Jun 19, 2012 at 2:30 PM, Vincent Hardy <vhardy@adobe.com<mailto:vhardy@adobe.com>> wrote:
Hi Stephen,

On Jun 19, 2012, at 11:20 AM, Stephen White wrote:

Hi FX-gurus,

As a followup to Method H "Tainting shader code branches" of the CSS Shaders Security document (http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security):

I don't know if this has been discussed previously, but another possible timing attack would be to use texture indirection:  using a source texture as a texture coordinate offset for another (large) texture might reveal performance differences:  "nearby" texel fetches in the second texture would be in texture cache, while "far" texels would be slower to retrieve.  I have not tested a proof-of-concept of this attack, but it should be possible to mitigate it simply by disallowing texture indirection via values retrieved from tainted textures.  This is really just a variant of the "No value dependent on the symbol u_texture may be an operand in an operation whose execution time can depend on the value of the operands" restriction:  texture2D() should probably be one of those operations.

Something like this:

vec4 color1 = texture2D(u_texture, v_texCoord);            // color1 is tainted
vec4 color2 = texture2D(u_bigImageTexture, color1.rg * vec2(500, 500)); // Error: cannot call texture2D() on expression using a tainted value

Stephen

We discussed texture indirection in the past in the context of DOS attacks, not timing attacks. My understanding is that with this method, we blow the cache on every access and can make shaders excecute really slowly, possibly resulting in a DOS (even though I have not seen this in action yet).

However, the current course of action is to prevent access to the rendered texture altogether so there should be no way to do a timing attach on the rendered content. A slow down is still possible with the technique you are bringing up. And a proof of concept is needed to assess how deep the DOS can be. I think Benoit had raised this in the past, may be he has hard data.

Yes, I meant my comment more for the control flow analysis "Method H" (which I think is captured here:  http://code.google.com/p/mvujovic/wiki/ShaderControlFlowAnalysis).   I realize that the current plan is to prevent access to the rendered texture altogether, which would definitely mitigate this issue as well (along with a host of other functionality, such as convolution).

My hope was that eventually the static analysis of shaders a la the above could be made robust enough to open up a wider range of functionality in CSS shaders, but that tainting texture indirection should be investigated before that happens.

ok, understood. For the record, Max did implement what you suggested. Unfortunately, at the moment, the approach is the safe but more limiting one (even though we have found that most of the use cases we had for CSS shaders so far are still possible).

Cheers,
-v


Stephen



For third party textures that can still be accessed by shaders, we are relying on CORS, so I believe the situation is exactly parallel to WebGL in that case.

Kind regards,
Vincent