4 ms·

//Black hat on The main concern for me with native client is webgl and the exposure of 3D device drivers to the Internet. These drivers were not written with t

by rakkhi 15y ago

//Black hat on The main concern for me with native client is webgl and the exposure of 3D device drivers to the Internet. These drivers were not written with this use in mind there have been webgl vulnerabilities in the past: http://www.contextis.com/research/blog/webgl2/ http://www.contextis.com/research/blog/webgl2/ While Google will be aware of these and actively working to provide a buffer with via validation and sandboxing, with pessimistic hat on, I can see this leading to a lot more security vulnerabilities.

tptacek 15y ago
That's a valid concern; I know another HN user who might chime in with more detail to back it up. On the other hand, Google has built a particularly good security team for low-level systems code problems like this, and they've done things (like the NaCL security contest) to attract the right kind of attention from researchers.
- daeken 15y ago
  I'm not the least bit concerned about NaCl's involvement here, but I'm still deeply scared by the potential for things to go very badly in the lower levels (but not enough so that I'm willing to disregard the benefits of these APIs, mind you). What it comes down to is that current GPUs do whatever you want with no concern for security; that part depends on the driver and userspace 3d stack. This isn't necessarily bad, but GPU manufacturers can't write code. Bounds checking and all that are pretty well covered by things like ANGLE (translates OGL to D3D on windows and acts as a sanity checker and shader validator everywhere else) but that doesn't help you if, say, your driver improperly compiles valid-but-malicious code. Avenues like that are effectively not researched at all.
  - nkassis 15y ago
    It's a concerned but it's something GPU vendors are claiming they are working on. There has been moves to improve driver security through the ARB_robustness extension and for the browser vendors there is the ANGLE's project as you have said but also plain blacklisting dangerous cards or drivers. The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight. In all, if we want a more capable web these are risk I feel are worth taking. But that's my personal view.
    - daeken 15y ago
      > There has been moves to improve driver security through the ARB_robustness extension IMO, GL_ARB_robustness is almost completely worthless. The one thing it gives you is the ability to time out rendering, in effect, which of course prevents certain types of DoS attacks. There are many other provisions in the extension, but those are already universally implemented in ANGLE and the like; they don't do anything to help with the security of the lower level. > The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight. NaCl has the same issues regardless of the sandbox, but I agree entirely: hardware accelerated 3d on the web is worth the risk we'll be dealing with for the first couple of years. I've stopped writing desktop 3d software/demos entirely in favor of WebGL simply because I believe so much in it, but it's not stopping me from doing security research into it as well. At the end of the day, I'm convinced that a reasonably skilled attacker could do terrible, terrible things to my system via WebGL. But the benefits outweigh the risks for me.
  - pmjordan 15y ago
    Virtualisation's rise in popularity has caused IOMMUs to start showing up even in some consumer chipsets. Do you think an IOMMU and a driver that supplies it appropriately restrictive page tables for the GPU will be enough or do we realistically need GPUs with some kind of native memory protection support that can somehow be intertwined with the CPU's process model?
    - daeken 15y ago
      Yes and no. So, it really depends on what you're defending against: if your concern is solely about an attacker using the GPU to compromise the CPU, then IOMMUs get you a lot in terms of restricting what's possible -- sure, an attacker could find some buffer somewhere in the accessible address space that they can use to attack the CPU, but it's another barrier. But if you think about what's on the GPU itself -- all your UI elements (in many cases), your webpages, etc -- it suddenly makes that data seem very important; if I can get you to go to a page that will let me grab all of your running windows, then suddenly I may very well have things like your passwords, credit card info, etc (all depending on when I grab the data and how often that data gets flushed out). I think that proper protections should be put in from the hardware on up through the drivers, but it's going to take a lot of work and a lot of research to get it right.
- drivebyacct2 15y ago
  I wonder how much Google feels comfortable with this level of risk due to the speed with which they are able to push out updates and the rate at which their clients autoupdate themselves.
evmar 15y ago
Your concern is valid, but I believe Native Client doesn't expose any more (GL) attack surface than JavaScript-based WebGL does.

by rakkhi 15y ago

tptacek 15y ago

That's a valid concern; I know another HN user who might chime in with more detail to back it up. On the other hand, Google has built a particularly good security team for low-level systems code problems like this, and they've done things (like the NaCL security contest) to attract the right kind of attention from researchers.

daeken 15y ago
I'm not the least bit concerned about NaCl's involvement here, but I'm still deeply scared by the potential for things to go very badly in the lower levels (but not enough so that I'm willing to disregard the benefits of these APIs, mind you). What it comes down to is that current GPUs do whatever you want with no concern for security; that part depends on the driver and userspace 3d stack. This isn't necessarily bad, but GPU manufacturers can't write code. Bounds checking and all that are pretty well covered by things like ANGLE (translates OGL to D3D on windows and acts as a sanity checker and shader validator everywhere else) but that doesn't help you if, say, your driver improperly compiles valid-but-malicious code. Avenues like that are effectively not researched at all.
- nkassis 15y ago
  It's a concerned but it's something GPU vendors are claiming they are working on. There has been moves to improve driver security through the ARB_robustness extension and for the browser vendors there is the ANGLE's project as you have said but also plain blacklisting dangerous cards or drivers. The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight. In all, if we want a more capable web these are risk I feel are worth taking. But that's my personal view.
  - daeken 15y ago
    > There has been moves to improve driver security through the ARB_robustness extension IMO, GL_ARB_robustness is almost completely worthless. The one thing it gives you is the ability to time out rendering, in effect, which of course prevents certain types of DoS attacks. There are many other provisions in the extension, but those are already universally implemented in ANGLE and the like; they don't do anything to help with the security of the lower level. > The reality is that web 3D's time seems to have arrived. It doesn't matter if it's through WebGL, Flash, Unity the issue you raised is present in all those solutions. Even Native client has that potential if the sandbox is not watertight. NaCl has the same issues regardless of the sandbox, but I agree entirely: hardware accelerated 3d on the web is worth the risk we'll be dealing with for the first couple of years. I've stopped writing desktop 3d software/demos entirely in favor of WebGL simply because I believe so much in it, but it's not stopping me from doing security research into it as well. At the end of the day, I'm convinced that a reasonably skilled attacker could do terrible, terrible things to my system via WebGL. But the benefits outweigh the risks for me.
- pmjordan 15y ago
  Virtualisation's rise in popularity has caused IOMMUs to start showing up even in some consumer chipsets. Do you think an IOMMU and a driver that supplies it appropriately restrictive page tables for the GPU will be enough or do we realistically need GPUs with some kind of native memory protection support that can somehow be intertwined with the CPU's process model?
  - daeken 15y ago
    Yes and no. So, it really depends on what you're defending against: if your concern is solely about an attacker using the GPU to compromise the CPU, then IOMMUs get you a lot in terms of restricting what's possible -- sure, an attacker could find some buffer somewhere in the accessible address space that they can use to attack the CPU, but it's another barrier. But if you think about what's on the GPU itself -- all your UI elements (in many cases), your webpages, etc -- it suddenly makes that data seem very important; if I can get you to go to a page that will let me grab all of your running windows, then suddenly I may very well have things like your passwords, credit card info, etc (all depending on when I grab the data and how often that data gets flushed out). I think that proper protections should be put in from the hardware on up through the drivers, but it's going to take a lot of work and a lot of research to get it right.
drivebyacct2 15y ago
I wonder how much Google feels comfortable with this level of risk due to the speed with which they are able to push out updates and the rate at which their clients autoupdate themselves.

evmar 15y ago

Your concern is valid, but I believe Native Client doesn't expose any more (GL) attack surface than JavaScript-based WebGL does.