4 ms·

What engineering did they do to reduce the security risk? As much as I like WebGL as a dev, Microsoft's arguments against feeding arbitrary machine code to bug

by idupree 13y ago

What engineering did they do to reduce the security risk? As much as I like WebGL as a dev, Microsoft's arguments against feeding arbitrary machine code to buggy graphics cards that have kernel-level memory access privileges... seemed a bit convincing.

mtgx 13y ago
It was just an excuse. The real reason is they didn't want to support anything OpenGL-based.
seanmcdirmid 13y ago
You know, the drivers could have just gotten better over time. Remember when Vista came out, they moved to a new driver model, and there were lots of bugs...people were worried about untrusted shader code bringing down machines (not quite security vulnerability, but definitely a DOS!). These days, the driver model is more mature, drivers that consumers have are a bit more robust, they probably re-evaluated their worries, which I think is great! Dynamism and flexibility is good in big.corp. Disclaimer: Microsoft employee, but speaking for myself.
pvnick 13y ago
Just want to reply to say I also would like to hear an answer to this question. Something I've wanted to do for a while is write a fuzzer [1] that puts together arbitrary garbage shader script code and runs it with weird webgl operations looking for exploitable crashes. I would expect there to be a ton of bugs found, but then again the monetary barrier to entry might be high considering differences between hardware. It also looks like the good folks at Mozilla have already been doing this to some degree [2], presumably shrinking the untested threat surface considerably (man I love those guys). [1] http://en.wikipedia.org/wiki/Fuzz_testing http://en.wikipedia.org/wiki/Fuzz_testing [2] https://bugzilla.mozilla.org/show_bug.cgi?id=665936 https://bugzilla.mozilla.org/show_bug.cgi?id=665936
- copperred 13y ago
  It would be an interesting project. You should go ahead and test the current implementations! Actually, would you even need webgl to hunt for GLSL exploits?
- cpeterso 13y ago
  Here's a WebGL fuzzer from Mozilla bug 614678: https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493971 https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493...
- _pmf_ 13y ago
  > Just want to reply to say I also would like to hear an answer to this question. The question is that they do what a business is required to do: let the market decide. Shockingly, the market does not want actual security; it wants lip service to make people feel safe and it wants shiny features.
- fulafel 13y ago
  This is happening and Google & Mozilla have both been dealing out bug bounties for vulnerabilities found this way. You can search for them in eg chrome bug db: https://encrypted.google.com/search?hl=en&q=site%3Acode.google.com+chromium+webgl+reward-topanel https://encrypted.google.com/search?hl=en&q=site%3Acode.goog... (this shows just the subset they've remembered to make public, some time after fixes were shipping in stable)
sampk 13y ago
Who cares. Typical way: Download game -> Confirm execution -> Play WebGL way: Confirm execution -> Play
- simpsond 13y ago
  As of right now, with WebGL enabled, there is no confirmation of execution... it just happens. One time confirmation of execution per domain per code load might be a good option.
- hudo 13y ago
  or: WebGL way: wait for textures and other stuff to download -> play
azakai 13y ago
I don't know anything about what Microsoft has done in particular. But I can tell you what other WebGL implementations do, for example: rewrite shaders to ensure their memory accesses are safe, not accept as valid shaders code that is dangerous (but would be valid GLSL in general), validate input to the graphics card (e.g., buffers are bound, avoids depending on the GL driver to check that), do fuzz testing, maintain blacklists of known buggy drivers, etc. etc. I would guess Microsoft is doing much the same, but it does have the extra advantage of only caring about one OS and also owning that OS.
randomfool 13y ago
Shader validation in ANGLE and black-listed drivers are how this is protected against in Chrome and Firefox. Microsoft was never really clear what the security issues were- really felt like a bunch of FUD.
cmccabe 13y ago
The security claims were bullshit. For details see: http://games.greggman.com/game/webgl-security-and-microsoft-bullshit/ http://games.greggman.com/game/webgl-security-and-microsoft-... tl;dr: While it was talking up the security risk of WebGL, Microsoft was allowing Silverlight to permit untrusted code to access graphics APIs in exactly the same way. Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.
- Paradigma11 13y ago
  But in SL you had to specifically and manually whitelist the website to allow access to the graphics api.
  - snogglethorpe 13y ago
    If it's a user-accessible WL, that doesn't actually add much security of course, because it's pretty simple to get users to add to the whitelist ("To play our awesome game online, open up the preferences dialogue and ...").
    - ajuc 13y ago
      It would be still useful to ask users before enabling WebGL on a site the first time. I would certainly think twice before enabling webgl if a site doesn't seem to need it. It could work like flash content with flashblock extention.
    - TheAnimus 13y ago
      >open up the preferences dialogue and Ultimately though, that is the difference between a drive by infection and user interaction required. In the same way people on the whole now are too savy to download the super-awesome-screensaver or whatever, plenty are smart enough to not say yes to some prompt. The security model of Silverlight dare is say, is superior to that of WebGL. The guys blog post doesn't actually help the issue of "Is WebGL a worrying attack vector?" instead it starts a seperate concern about Silverlight.
gavanwoolery 13y ago
I agree that the threat is present, but rather than restrict freedom it is better to place decisions in the user's hands sometimes. There are security threats everywhere, even beyond the software or hardware level (i.e. phishing for passwords). I think that rather than not implement WebGL, it would be better to ask permission if the user trusts the domain (just as Chrome does with any plugin).
fulafel 13y ago
> Microsoft's arguments against feeding arbitrary machine code to buggy graphics cards That would indeed be a bad idea. This is not how WebGL works. There's a translation layer that gets the WebGL calls and relays them to the graphics drivers after determining the calls are safe. This layer can have bugs of course, like other sandboxes (javascript, flash, etc).

by idupree 13y ago

mtgx 13y ago

It was just an excuse. The real reason is they didn't want to support anything OpenGL-based.

seanmcdirmid 13y ago

You know, the drivers could have just gotten better over time. Remember when Vista came out, they moved to a new driver model, and there were lots of bugs...people were worried about untrusted shader code bringing down machines (not quite security vulnerability, but definitely a DOS!). These days, the driver model is more mature, drivers that consumers have are a bit more robust, they probably re-evaluated their worries, which I think is great! Dynamism and flexibility is good in big.corp. Disclaimer: Microsoft employee, but speaking for myself.

pvnick 13y ago

Just want to reply to say I also would like to hear an answer to this question. Something I've wanted to do for a while is write a fuzzer [1] that puts together arbitrary garbage shader script code and runs it with weird webgl operations looking for exploitable crashes. I would expect there to be a ton of bugs found, but then again the monetary barrier to entry might be high considering differences between hardware. It also looks like the good folks at Mozilla have already been doing this to some degree [2], presumably shrinking the untested threat surface considerably (man I love those guys). [1] http://en.wikipedia.org/wiki/Fuzz_testing http://en.wikipedia.org/wiki/Fuzz_testing [2] https://bugzilla.mozilla.org/show_bug.cgi?id=665936 https://bugzilla.mozilla.org/show_bug.cgi?id=665936

copperred 13y ago
It would be an interesting project. You should go ahead and test the current implementations! Actually, would you even need webgl to hunt for GLSL exploits?
cpeterso 13y ago
Here's a WebGL fuzzer from Mozilla bug 614678: https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493971 https://bug614678.bugzilla.mozilla.org/attachment.cgi?id=493...
_pmf_ 13y ago
> Just want to reply to say I also would like to hear an answer to this question. The question is that they do what a business is required to do: let the market decide. Shockingly, the market does not want actual security; it wants lip service to make people feel safe and it wants shiny features.
fulafel 13y ago
This is happening and Google & Mozilla have both been dealing out bug bounties for vulnerabilities found this way. You can search for them in eg chrome bug db: https://encrypted.google.com/search?hl=en&q=site%3Acode.google.com+chromium+webgl+reward-topanel https://encrypted.google.com/search?hl=en&q=site%3Acode.goog... (this shows just the subset they've remembered to make public, some time after fixes were shipping in stable)

sampk 13y ago

Who cares. Typical way: Download game -> Confirm execution -> Play WebGL way: Confirm execution -> Play

simpsond 13y ago
As of right now, with WebGL enabled, there is no confirmation of execution... it just happens. One time confirmation of execution per domain per code load might be a good option.
hudo 13y ago
or: WebGL way: wait for textures and other stuff to download -> play

azakai 13y ago

I don't know anything about what Microsoft has done in particular. But I can tell you what other WebGL implementations do, for example: rewrite shaders to ensure their memory accesses are safe, not accept as valid shaders code that is dangerous (but would be valid GLSL in general), validate input to the graphics card (e.g., buffers are bound, avoids depending on the GL driver to check that), do fuzz testing, maintain blacklists of known buggy drivers, etc. etc. I would guess Microsoft is doing much the same, but it does have the extra advantage of only caring about one OS and also owning that OS.

randomfool 13y ago

Shader validation in ANGLE and black-listed drivers are how this is protected against in Chrome and Firefox. Microsoft was never really clear what the security issues were- really felt like a bunch of FUD.

cmccabe 13y ago

The security claims were bullshit. For details see: http://games.greggman.com/game/webgl-security-and-microsoft-bullshit/ http://games.greggman.com/game/webgl-security-and-microsoft-... tl;dr: While it was talking up the security risk of WebGL, Microsoft was allowing Silverlight to permit untrusted code to access graphics APIs in exactly the same way. Chrome validates everything before calling the actual driver APIs, so the opportunities for fuzzing are limited.

Paradigma11 13y ago
But in SL you had to specifically and manually whitelist the website to allow access to the graphics api.
- snogglethorpe 13y ago
  If it's a user-accessible WL, that doesn't actually add much security of course, because it's pretty simple to get users to add to the whitelist ("To play our awesome game online, open up the preferences dialogue and ...").
  - ajuc 13y ago
    It would be still useful to ask users before enabling WebGL on a site the first time. I would certainly think twice before enabling webgl if a site doesn't seem to need it. It could work like flash content with flashblock extention.
  - TheAnimus 13y ago
    >open up the preferences dialogue and Ultimately though, that is the difference between a drive by infection and user interaction required. In the same way people on the whole now are too savy to download the super-awesome-screensaver or whatever, plenty are smart enough to not say yes to some prompt. The security model of Silverlight dare is say, is superior to that of WebGL. The guys blog post doesn't actually help the issue of "Is WebGL a worrying attack vector?" instead it starts a seperate concern about Silverlight.

gavanwoolery 13y ago

I agree that the threat is present, but rather than restrict freedom it is better to place decisions in the user's hands sometimes. There are security threats everywhere, even beyond the software or hardware level (i.e. phishing for passwords). I think that rather than not implement WebGL, it would be better to ask permission if the user trusts the domain (just as Chrome does with any plugin).

fulafel 13y ago

> Microsoft's arguments against feeding arbitrary machine code to buggy graphics cards That would indeed be a bad idea. This is not how WebGL works. There's a translation layer that gets the WebGL calls and relays them to the graphics drivers after determining the calls are safe. This layer can have bugs of course, like other sandboxes (javascript, flash, etc).