Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)

[Steve Baker <steve@sjbaker.org>]

> All this makes me wonder if all query operations on the framebuffer need to be disallowed for a tainted framebuffer. For instance, GL_ARB_occlusion_query (which we don't support now, but conceivably could in the future) gives the author information about the contents of the framebuffer. Could a clever author somehow use this to determine the color values of a texture? If so, we would have to disallow this extension or at least access to the occlusion query results if the framebuffer is tainted. 
>   
Well, you could certainly figure out the contents of the depth and maybe
stencil buffers using occlusion testing.  He could maybe run a shader
that copies the texel color into Z depth and then use a bazillion
occlusion queries to probe the depth at each pixel in turn - so yeah - I
think it could be done if one were sufficiently determined.

If I put on my black hat on for a moment, I think I could do it without
needing the occlusion query extension:

1) Write a shader that tests the color at a particular texel of the
texture and loops such as to consume an amount of time proportional to
the brightness of the texel.
2) Draw a large number of tiny triangles to probe each texel in
turn...enough to get a variation in timing that you can measure in the
app despite FIFO delays, scheduling, etc.
3) Measure how long the rendering for each texel takes to execute.
4) Normalize the results into a 0..1 scale.
5) Pack the resulting normalized times into an array and voila!  You
have a monochrome image...not exact grey shades perhaps - but plenty
good enough to read text.
6) Rinse and repeat and you have a color image.

If you know something about the structure of the image (like if you know
it's text in a particular font) - then you can probably use the average
brightness of each letter in the font and figure out most of what was
written with far fewer tests...and if you can live with reading back a
lower resolution image - then you can do it much faster.

But if you're getting into those kinds of realms of paranoia - how about
the bad guy simply queries the loaded shaders to find out the variable
names and types of the inputs they are requesting?  There is enough
information there to figure out which application is running.  Hence the
bad guy knows something about what the end user is doing.  I could
imagine an unscrupulous data gatherer wanting to know what applications
a particular person is running.

Just how paranoid do we have to be?

  -- Steve.

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: