[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] CORS and resource provider awareness



I could not find math exploits yet. However that does not rule out that they might exist in some hardware (but mine). But those aren't the only attack vectors left. There is also stenciling based approaches, anti-aliasing/coverage exploits, NaN exploits, any of the other functions might exhibit performance differences, compiler optimizations might add conditionals, and so on.

This seems to me to be some kind of attempt at an end-run around a more or less general purpose machine with lots and lots of unknowns (driver, hardware, implementation details etc.). I'd rather not the standard would try the leaking sieve security approach and just accept that timing attacks are possible long as you can execute code on a machine, and that it has to address the issue facing this fact.


On Mon, Nov 5, 2012 at 3:40 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
My understanding is that the proposed restrictions on the shader language already ban dependent texture lookups, so that they should be able to block this particular attack.

However, the opinion that I have already expressed here and on public-fx in the past, and that I still adhere to, is that even with only plain arithmetic operations and built-in math functions, and no branching or dependent texture lookups, it is already too dangerous to rely on the assumption that no timing attack exists.

My reasons to believe that are:

 - On intel-compatible CPUs with x87 instructions, plain arithmetic instructions (add, mul) can take over 100x longer if some of the operands is non-finite. See http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0038.html . The objection to my argument was that just because this is the case with x87 instructions does not imply that it is the case with any current GPU. The point that I tried --- and failed --- to convey, is that this is too much detail to base the security of a Web standard on.

 - I hadn't started yet timing math functions such as sqrt/sin/tan etc, yet it is virtually impossible to implement them in a way that takes the same amount of time for all inputs. These functions are implemented in 2 phases: phase 1 takes an arbitrary number and reduce to the case where the number is in a given small segment; phase 2 implements the function as a polynomial approximation on this segment. It is phase 1 that is, for many math functions such as the trigonometric ones, very hard or impossible to implement with constant-run-time constraints. For logarithmic functions this is made relatively easy by the fact that the input number is already given in exponent form (mantissa * 2^exponent). For other functions this is hard and would come at the cost of a performance compromise. It's a bit optimistic to expect all GPU vendors to have already chosen such compromises to guarantee constant execution. If someone is interested in experimenting this, I would start with the sqrt and pow functions (try very large/small values), and continue with sin (try 2 things: very large values, and different locations in the [0;2pi] period interval).

Benoit




On 12-11-05 08:54 AM, Florian Bösch wrote:
Based on this finding I wondered if restricting VS texture access + control flow restrictions would work. I do not think it would work.

Proof attack without VS texture access and without control flow constructs in the shader: http://codeflow.org/issues/timing-attack/cache-coherence.html
Working principle: Texel fetches are cached by the GPU. By adding a random offset to the texel fetch based on the pixel luminance in question the vertex shader can be made to run different lengths of time.


On Mon, Nov 5, 2012 at 1:09 PM, Florian Bösch <pyalot@gmail.com> wrote:
I don't think restrictions on control flow constructs are a reliable way to prevent timing attacks.

Proof attack without control flow constructs in the shader: http://codeflow.org/issues/timing-attack/vs-tex.html
Working principle: A quad is overdrawn on a canvas 128x and the quad size depends on the texel value fetched from texture.