[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)
Brian Cornell wrote:
> If I understand the WebGL shader limitations correctly, you black hat
> solution would not work because loops that can't be statically
> unrolled are not allowed. So you could not use a loop based on the
> texel value.
If you did a pixel 'discard' inside an 'if' statement many modern cards
would do an early-out of the shader if all of the adjacent pixels
terminated early. No amount of legalese in the spec will prevent that
from happening if that's what the hardware actually does:
for ( i = 0 ; i < 256 ; i++ )
if ( i > texelBrightness*255 )
read a random texel out of a huge map ;
But it doesn't matter...I just thought of something even easier. Even
if the vertex and pixel shaders take absolutely the same amount of time
no matter what - I can STILL just do this at the end if the vertex shader:
gl_Position = vertexPosition.xy * texelBrightness ;
...then I bind the texture to a vertex shader sampler and draw a large
quad in the center of the screen.
The size of the quad will be proportional to the square of the texel
brightness - and the number of pixels we'll draw will be roughly
proportional to the brightness - and with finite frame buffer memory
speeds that's got to impact the pixel processing time in a sufficiently
predictable way for this hack to work. For a useful exploit we might
only need to be able to read a 100x20 texel patch of white text on a
black background and we've stolen someone's credit card number. You'd
only need to distinguish black from white...a simple timing threshold
would suffice. Text is pretty readable even in the presence of
considerable noise - so random timing variations would be little
obstacle to the determined bad guy.
So there are plausible exploits even with readTexels and occlusion
culling completely disabled.
The trouble is that this is the kind of thing that 10 minutes of me
thinking about it can turn up. Bad guys trying to recover passwords or
credit card numbers will be thinking about this for months or even years
- there are an unbelievable number of tiny chinks in the armor that
could possibly be exploited.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: