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: Stephen White <senorblanco@chromium.org>
Date: Tue, 19 Jun 2012 14:49:20 -0400
Message-ID: <CAPeKFThRU8XpMY7OBDhu8rS60G-mgYmsWRupR=O6vHf3WBXOCw@mail.gmail.com>
To: Vincent Hardy <vhardy@adobe.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>
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.


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

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