4 ms·

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

by 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).

by daeken 15y ago

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).