5 ms·

I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Even if Microsoft fixes this particular i

I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Even if Microsoft fixes this particular issue, they either can't fix every possible variation or the same techniques that make this fixable can be used to fix it in WebGL. As long as you can send an arbitrary shader (which is essentially a small piece of executable code that GPU executes) to a GPU, you can overload the GPU. This capability is available in WebGL, Silverlight 5 and Flash. You don't want to remove this capability, because it's the core reason GPUs can do some things so much faster than a CPU. You can try to sanitize shaders as much as possible (and I'm sure both Silverlight and WebGL implementation will do their best) but it's not even theoretically possible to decide a time complexity of arbitrary assembly code. Writing code is about features vs. risk trade offs. Microsoft clearly has decided that the risks are acceptable for Silverlight but somehow the same category of risks is not acceptable for WebGL. And if you ask me, I agree with WebGL folks and the Silverlight part of Microsoft. The worst that can happen is slowing down your computer. This is an annoyance but also an issue we encounter daily: both my Mac and Windows software, including the OSes, crash and misbehave rather regularly. I accept that because the annoyance that it causes is much less important than my desire to use the software. It's also an annoyance that can be generated with technologies that already are part of the browser. A web page can exhaust any computer's memory (causing swapping) but sending arbitrarily large images. It's easy to write JavaScript that will eat CPU cycles. It's easy to DOS a browser by creating arbitrarily complex DOM and update it frequently enough. All those issues can be mitigated by browser implementors but none of them can really be fixed. And yet we happily use the internet and we'll happily keep using it after WebGL is implemented.

daeken 15y ago
From a security perspective, a shader-based DoS is annoying, but not a huge issue. Arbitrary code execution, potentially in the kernel, is. There are just too many moving pieces, too many un/poorly-tested components, and too little standing between a webpage and the kernel for my liking. While I want WebGL to become huge (I really dig it), from a security standpoint I simply can't support it in its current incarnation, and won't for a long while most likely. That said, these are not inherent design flaws, just realities of the stack it's on.
- magicalist 15y ago
  shaders are not arbitrary code nor are they executed in the kernel. the same goes with API calls. while opening APIs to new parts of a system always exposes new risks, specious reasoning is not sufficient to determine if the risks are manageable and mitigable. notice that khronos and the webgl implementers have not responded with content-less dismissals of these concerns. they have outlined the exact steps they've taken to secure their API from the limits of the GPU model and their work to prevent buggy GPUs/drivers from executing webgl content at all. If someone can actually demonstrate (or even speculate on a mechanism of action of) an actual attack that isn't addressed by their current systems or (in the case of DoS attacks) their ongoing work with OS and GPU vendors, then we can talk about fundamentally flawed. Until then it's a matter of risk assessment.
  - magicalist 15y ago
    just to be clear, I certainly did not mean "specious" here as a personal attack. I meant it in the sense that it is easy to talk about buggy drivers -- every one of us has encountered some kind of instability or crash from them -- but security assessments rely on specifics. If a group is claiming that this kind of system interaction is securable (for some given definition of "securable"), we can evaluate both that claim and if that level of security is sufficient. For instance, we can enumerate the ways that WebGL can interact with buffers; given those, what attacks are possible at those points and how are they being defended against? Obviously a web forum isn't the best place for this, but it's important to keep in mind.
  - daeken 15y ago
    I never said that shaders are arbitrary code or that they're executed in the kernel. WebGL in general opens up a huge attack surface, however, much of which is in the kernel. As soon as WebGL hit Webkit, I started testing it for two reasons: 1) I do 3d art, and 2) I work in security. I understand the systems involved quite well, and I'm still very concerned about it.
- wladimir 15y ago
  "Arbitrary code execution, potentially in the kernel". Luckily, the kernel component of graphics drivers (at least the NVIDIA one) is comparatively small these days, and mainly concerns memory/buffer allocation and resource scheduling. Apart from that, it provides a memory-mapped command queue directly to the GPU. Memory protection is enforced in hardware. The user-space part of the driver, on the other hand, is the complex beast that handles all the GL rendering commands. It's much more likely that an exploit would happen there (still not good, but heh it sounds less scary and can be controlled with user-space security restrictions).
bonch 15y ago
I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Microsoft's reply is at the top of the comments to the article and reads: "DoS mitigations are implemented in current internal builds and will ship with Silverlight 5 RTM." I get that the anti-Microsoft droids are out in full force after the article from that Google employee, but come on, a little reading goes a long way.
- SigmundA 15y ago
  So do the same thing in a WebGL implementation in IE? Either way it's hypocritical.

daeken 15y ago

From a security perspective, a shader-based DoS is annoying, but not a huge issue. Arbitrary code execution, potentially in the kernel, is. There are just too many moving pieces, too many un/poorly-tested components, and too little standing between a webpage and the kernel for my liking. While I want WebGL to become huge (I really dig it), from a security standpoint I simply can't support it in its current incarnation, and won't for a long while most likely. That said, these are not inherent design flaws, just realities of the stack it's on.

magicalist 15y ago
shaders are not arbitrary code nor are they executed in the kernel. the same goes with API calls. while opening APIs to new parts of a system always exposes new risks, specious reasoning is not sufficient to determine if the risks are manageable and mitigable. notice that khronos and the webgl implementers have not responded with content-less dismissals of these concerns. they have outlined the exact steps they've taken to secure their API from the limits of the GPU model and their work to prevent buggy GPUs/drivers from executing webgl content at all. If someone can actually demonstrate (or even speculate on a mechanism of action of) an actual attack that isn't addressed by their current systems or (in the case of DoS attacks) their ongoing work with OS and GPU vendors, then we can talk about fundamentally flawed. Until then it's a matter of risk assessment.
- magicalist 15y ago
  just to be clear, I certainly did not mean "specious" here as a personal attack. I meant it in the sense that it is easy to talk about buggy drivers -- every one of us has encountered some kind of instability or crash from them -- but security assessments rely on specifics. If a group is claiming that this kind of system interaction is securable (for some given definition of "securable"), we can evaluate both that claim and if that level of security is sufficient. For instance, we can enumerate the ways that WebGL can interact with buffers; given those, what attacks are possible at those points and how are they being defended against? Obviously a web forum isn't the best place for this, but it's important to keep in mind.
- daeken 15y ago
  I never said that shaders are arbitrary code or that they're executed in the kernel. WebGL in general opens up a huge attack surface, however, much of which is in the kernel. As soon as WebGL hit Webkit, I started testing it for two reasons: 1) I do 3d art, and 2) I work in security. I understand the systems involved quite well, and I'm still very concerned about it.
wladimir 15y ago
"Arbitrary code execution, potentially in the kernel". Luckily, the kernel component of graphics drivers (at least the NVIDIA one) is comparatively small these days, and mainly concerns memory/buffer allocation and resource scheduling. Apart from that, it provides a memory-mapped command queue directly to the GPU. Memory protection is enforced in hardware. The user-space part of the driver, on the other hand, is the complex beast that handles all the GL rendering commands. It's much more likely that an exploit would happen there (still not good, but heh it sounds less scary and can be controlled with user-space security restrictions).

bonch 15y ago

I'm glad that someone demonstrated Microsoft's FUD and their double-standards for security with a simple bit of code. Microsoft's reply is at the top of the comments to the article and reads: "DoS mitigations are implemented in current internal builds and will ship with Silverlight 5 RTM." I get that the anti-Microsoft droids are out in full force after the article from that Google employee, but come on, a little reading goes a long way.

SigmundA 15y ago
So do the same thing in a WebGL implementation in IE? Either way it's hypocritical.