[bmm6o]

> I wouldn't consider crash bugs in general security issues

You should, until proven otherwise. If it crashes because it's reading an invalid memory location (for instance), it's a matter of time before someone figures out how to place executable code there.

I have no problem with MS's original position. WebGL forces your hardware drivers to run random code downloaded from the internet. I'm frankly surprised that the other browser vendors ran ahead with it so quickly and that we haven't heard about any exploits caused by it.

[yuhong]

On that matter, it is not difficult for someone who knows how to use WinDbg or similar to see if a crash is exploitable. For example, in user mode, null pointer accesses are generally not exploitable. I personally was able to get an IE6/IE7 bug described in http://www.satzansatz.de/cssd/pseudocss.html#fltadjacent fixed in the May 2013 security update by proving there is an exploitable crash.

[gsnedders]

Most crashes as shipped are just the shader over running maximum time and it being killed, AIUI, rather than actual segmentation faults or attempts to read garbage. Most actual known issues that are potentially security concerns are worked around through preprocessing what the driver gets, and given the level of testing I don't worry about it more than any other OS component security wise. The biggest risk would probably be a new driver release shipping with bug leading to exploitable code being executed.

Also, if I'm not mistaken Chrome shipped first: and they'd done masses of fuzzing of both their code and the drivers. Nobody really rushed into it, everyone keeping it off by default for an unusually long time to catch issues before shipping.