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

On Tue, Jun 19, 2012 at 2:30 PM, Vincent Hardy <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.

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
>
>
>
>