Google nabs Square Enix and other game developers for native client Chrome games
1–10 of 47 posts
Re: Google nabs Square Enix and other game developers for native client Chrome games
#2//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/
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.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#3Iiiiinteresting. They mention Bastion, which is built with XNA and C#. I wonder how they plan on porting it.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#4//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/ 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…
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.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#5//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/ 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…
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.
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.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#6Iiiiinteresting. They mention Bastion, which is built with XNA and C#. I wonder how they plan on porting it.
Bastion runs on Mono, and Mono runs on native client (including the JIT, which required some special work in native client itself).
Actually all three apps they demo'd running on native client were also running on Mono!
Re: Google nabs Square Enix and other game developers for native client Chrome games
#7Iiiiinteresting. They mention Bastion, which is built with XNA and C#. I wonder how they plan on porting it.
Bastion runs on Mono, and Mono runs on native client (including the JIT, which required some special work in native client itself). Actually all three apps they demo'd running on native client were also running on Mono!
Oh wow, nice. The original version of NaCl didn't allow any runtime codegen -- when did that change?
Re: Google nabs Square Enix and other game developers for native client Chrome games
#8//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/ 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…
Your concern is valid, but I believe Native Client doesn't expose any more (GL) attack surface than JavaScript-based WebGL does.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#9There you go: Google's embrace, extend, extinguish. Just like MS, but with better cover. "Its open!"
Of course, no one else will implement.
Re: Google nabs Square Enix and other game developers for native client Chrome games
#10Iiiiinteresting. They mention Bastion, which is built with XNA and C#. I wonder how they plan on porting it.
Bastion runs on Mono, and Mono runs on native client (including the JIT, which required some special work in native client itself). Actually all three apps they demo'd running on native client were also running on Mono!
Do you know what the solution was for XNA? The last time I checked, all the Mono XNA ports were in miserable shape. Considering Bastion makes use of shaders and mixed mode 2d/3d rendering, it seems like it must be running on a high quality port of a large portion of the XNA stack.