5 ms·

Yeah we found really dismal support for X3100 hardware. It doesn't support the return statement in vertex or fragment shaders due to a driver bug, and it doesn

Yeah we found really dismal support for X3100 hardware. It doesn't support the return statement in vertex or fragment shaders due to a driver bug, and it doesn't support gl_PointCoord in the fragment shader. Yet chrome and firefox would allow this hardware to open a WebGL context, with no warning that these basic features of OpenGL are not supported.

marshray 15y ago
Perhaps you see why some of us are skeptical when WebGL's proponents downplay concerns about it enabling security bugs. The hardware provides a full-featured CPU with DMA access to the host's memory. Everything better go just right, or it's going to end up remotely exploitable.
- AshleysBrain 15y ago
  I think it's unfair to call out WebGL specifically when the same is theoretically possible in Flash 11's Stage3D and Silverlight 5's Direct3D.
  - marshray 15y ago
    Fair enough, but that's not really a very good argument for its inherent security either. There is a long history of problems with Flash. Silverlight has had vulnerabilities as well. But those are 3rd party binary plugins. It's a lot easier to disable, uninstall, and move beyond 3rd party plugins than it is widely-adopted standards implemented by the browser vendors themselves. It's because it is so appealing and has the potential to become quite popular that we're talking about it now.
  - luriel 15y ago
    Just because other technologies are even worse doesn't make WebGL's security any more acceptable. John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security."
- Klinky 15y ago
  The hardware provides a full-featured CPU with DMA access to the host's memory. What part of WebGL gives a programmer unrestricted access to the host's memory? Everything better go just right, or it's going to end up remotely exploitable. The same could be said for practically any program or web app. Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML... - http://secunia.com/advisories/12959/ http://secunia.com/advisories/12959/
  - marshray 15y ago
    What part of WebGL gives a programmer unrestricted access to the host's memory? Ever had a video driver bug crash an application or bluescreen Windows? Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML It's a fair point. Security is about trade-offs. I am indeed concerned about HTML and do most browsing in a VM. But to me WebGL is farther out on the risk/benefit spectrum than HTML. I would not accept it for ads or ordinary page content. I would consider enabling it selectively for an app that I carefully decided to trust. * Admittedly I have not tried, but I suspect it's going to be very difficult to get it to work well from within a VM. * HTML parsers and renderers have indeed had plenty of vulnerabilities. They have taken years to get as secure as they are today and we may not have seen the last of the exploitable bugs in them. * HTML parsers have been implemented from the beginning to accept untrusted data from the internet. 3D graphics drivers, on the other hand, are designed primarily for performance in a scenario where they are run by a single-user game on the local machine, often with Admin privs already. * We saw how many years it took Microsoft (the company that could reportedly turn on a dime) to 'get' security to the point that they could ship a secure browser. I don't see much evidence that graphics vendors are even thinking about it yet. * Apple knows that WebGL bugs will result in jailbroken iPhones. Guess how many years their OpenGL support level is behind the PC...on the very same GPU hardware? Last I checked, someone reported getting OpenGL 3.2 working on a Mac. I've had usable OpenGL 3.3 on a freaking Linux laptop for a couple of years now. More powerful GPUs are up at 4.2. * A buffer overflow in HTML does not automatically amount to a kernel level compromise, (some recent font handling bugs in Windows notwithstanding :-). In fact, the latest generation of sandboxed browsers are building defense in depth mitigations. Any buffer mismanagement between the GPU, driver, GL, and WebGL seems very likely to result in complete pwnage. The GPU can access host memory directly with no access permissions. Don't get me wrong - I love the idea of WebGL and want it to succeed. I just would hate to see it end up like Flash, struggling for years to retrofit security onto something that wasn't originally spec'd for it and a bunch of its users getting pwned in the process.

marshray 15y ago

Perhaps you see why some of us are skeptical when WebGL's proponents downplay concerns about it enabling security bugs. The hardware provides a full-featured CPU with DMA access to the host's memory. Everything better go just right, or it's going to end up remotely exploitable.

AshleysBrain 15y ago
I think it's unfair to call out WebGL specifically when the same is theoretically possible in Flash 11's Stage3D and Silverlight 5's Direct3D.
- marshray 15y ago
  Fair enough, but that's not really a very good argument for its inherent security either. There is a long history of problems with Flash. Silverlight has had vulnerabilities as well. But those are 3rd party binary plugins. It's a lot easier to disable, uninstall, and move beyond 3rd party plugins than it is widely-adopted standards implemented by the browser vendors themselves. It's because it is so appealing and has the potential to become quite popular that we're talking about it now.
- luriel 15y ago
  Just because other technologies are even worse doesn't make WebGL's security any more acceptable. John Carmack: "I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security."
Klinky 15y ago
The hardware provides a full-featured CPU with DMA access to the host's memory. What part of WebGL gives a programmer unrestricted access to the host's memory? Everything better go just right, or it's going to end up remotely exploitable. The same could be said for practically any program or web app. Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML... - http://secunia.com/advisories/12959/ http://secunia.com/advisories/12959/
- marshray 15y ago
  What part of WebGL gives a programmer unrestricted access to the host's memory? Ever had a video driver bug crash an application or bluescreen Windows? Your web browser could have a buffer overflow in it's HTML parsing engine, yet I don't hear you speaking out against HTML It's a fair point. Security is about trade-offs. I am indeed concerned about HTML and do most browsing in a VM. But to me WebGL is farther out on the risk/benefit spectrum than HTML. I would not accept it for ads or ordinary page content. I would consider enabling it selectively for an app that I carefully decided to trust. * Admittedly I have not tried, but I suspect it's going to be very difficult to get it to work well from within a VM. * HTML parsers and renderers have indeed had plenty of vulnerabilities. They have taken years to get as secure as they are today and we may not have seen the last of the exploitable bugs in them. * HTML parsers have been implemented from the beginning to accept untrusted data from the internet. 3D graphics drivers, on the other hand, are designed primarily for performance in a scenario where they are run by a single-user game on the local machine, often with Admin privs already. * We saw how many years it took Microsoft (the company that could reportedly turn on a dime) to 'get' security to the point that they could ship a secure browser. I don't see much evidence that graphics vendors are even thinking about it yet. * Apple knows that WebGL bugs will result in jailbroken iPhones. Guess how many years their OpenGL support level is behind the PC...on the very same GPU hardware? Last I checked, someone reported getting OpenGL 3.2 working on a Mac. I've had usable OpenGL 3.3 on a freaking Linux laptop for a couple of years now. More powerful GPUs are up at 4.2. * A buffer overflow in HTML does not automatically amount to a kernel level compromise, (some recent font handling bugs in Windows notwithstanding :-). In fact, the latest generation of sandboxed browsers are building defense in depth mitigations. Any buffer mismanagement between the GPU, driver, GL, and WebGL seems very likely to result in complete pwnage. The GPU can access host memory directly with no access permissions. Don't get me wrong - I love the idea of WebGL and want it to succeed. I just would hate to see it end up like Flash, struggling for years to retrofit security onto something that wasn't originally spec'd for it and a bunch of its users getting pwned in the process.