Comment by lucian1900
10 years ago
Exactly.
Every sandboxed app ever has needed native access of some sort to do something useful.
The best example of this difficulty is probably graphics (WebGL). To provide a compelling user experience, the API must allow apps to upload almost arbitrary code (shaders).
I'm genuinely curious what WebGL shaders can be used to do maliciously, and in what ways they can be considered arbitrary code?
They are arbitrary code, they just have to be written in GLSL. One of the vectors is the fact that less effort has been put into isolating and securing GPU memory, since previously, it was not considered sensitive. This is compounded by the fact that WebGL shader code and API calls are often processed by a layer with escalated privileges, written in C or C++, completely opaque, with lots of unknown bugs.
http://www.kitguru.net/gaming/security-software/carl/webgl-e...
http://www.contextis.com/resources/blog/webgl-more-webgl-sec...
http://www.pcworld.com/article/227438/dangerous_webgl_flaw_p...
Can you be more specific about what you mean by arbitrary code? I agree the code can be arbitrary GLSL, but what are the actual risks? GLSL doesn't have access to the CPU, network, filesystem, peripherals, or anything other than (indirectly) VRAM, as far as I know. If I'm wrong, please help me understand.
My feeling having written a few GLSL shaders is that the language is already sandboxed by design, making it a safer environment to execute 'arbitrary code' than just about any other viable option. In a shader, I get access only to the input I'm given, and can only affect the color of a pixel, and nothing more.
The 'graphics memory theft' exploit (your 2nd link) cannot have been a primary result of a GLSL exploit, as I understand it. That would have required use of an improperly authorized API call like glGetPixels(), and so arbitrary code execution is not the issue there. WebGL's API design and the browser's sandboxing are accountable -- and anyway, it sounds like that got fixed a long time ago?
The first link says the main risk is crashing, so some sort of DOS attack I suppose. That is true of all computing systems, and also isn't exclusive to arbitrary code execution. I'd speculate it's probably easier to get WebGL to crash using the API than shaders. Either way yes, this is a risk, but not particularly specific to WebGL and not the worst kind of security risk in most environments unless combined with something else. (I grant that crashes in hospital equipment, for example, is a high security risk. Then again, most hospitals don't actually let their sensitive equipment browse the web for a reason.)
What other real risks are there, to the average person surfing the web?
Those 3 links are all to the same issue that was closed long ago and funded by MS as FUD.
There haven't been any real WebGL exploits I know of. No you can't upload arbitrary shaders either. They're validated and then re-written by the browsers.
1 reply →