W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

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

From: Vincent Hardy <vhardy@adobe.com>
Date: Tue, 19 Jun 2012 11:30:25 -0700
To: Stephen White <senorblanco@chromium.org>
CC: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <37A88011-1921-4DF4-846F-AF02C273A116@adobe.com>
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


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.

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,
Received on Tuesday, 19 June 2012 18:31:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:47 UTC