Hacker News Reader

Comment by nailer | Hacker News Reader

A lot of people hated the decision, but back when Microsoft refused to support WebGL, one of the reasons were that the GPU drivers were awful and exposing them to the internet was dangerous.

The proper solution, of course, i for GPU drivers not to suck but it was still a legitimate point and this article seems to validate that.

View on HN

They were right that it was dangerous, but it became pretty clear that IE was using them to provide cover for not implementing a feature when they changed their mind later.

Whereas Chrome implemented a WebGL compiler that reduced the amount of attack surface WebGL could reach and audited a bunch of popular drivers to fix the exposed bits.

I think the fact that this blog shows that these vulnerabilities are not reachable from WebGL is a validation of Chrome's approach there, though it clearly shows the issues these drivers present for escaping Chrome's sandbox.

I think there's probably still a fair bit of attack surface behind glReadPixels() and the like. All it takes in a single backbuffer/texture/surface/etc to not be memzero'd properly and you can start looking at parts of the system's memory.

GPUs are both really complex and highly secretive about their implementations. The incentive for GPU vendors is to write fast drivers. Security is pretty far down on the list, esp when it competes directly against performance.

>fair bit of attack surface behind glReadPixels() and the like...

>...you can start looking at parts of the system's memory

I thought the whole point of using glReadPixels(), as opposed to just dereferencing a pointer in the system's address space, was that the framebuffer memory it accesses (whether backed by a texture or a surface or whatever) is GPU memory, and not system memory?

That's true on split-memory architectures(desktop) but most mobile GPUs(and a couple consoles) use a unified memory model.

Also most browsers use the GPU to speed up rendering so you can pick out things from there too potentially.

I wonder, do you really have to write zero to all the memorycells? Or can you just stop the refresh cycle in hardware and let squares of memory drain and die in one or two cycles?

Even without refreshing the cells they actually last quite a lot longer than you would expect. This is an old research paper on the topic but unfortunately, it looks like all of the images and videos are broken which is a shame because it gave you a great mental picture of the "half-life" so to speak of RAM.

https://citp.princeton.edu/research/memory/

The bottom line is that you would need to stop refreshing it for minutes if not longer to be sure that there wasn't an information leak and if the memory is cooled down it'll last a great deal longer without being refreshed and even still keep the majority of the contents after hours of being removed from a running system if they are cooled using liquid nitrogen. Either way one or two cycles isn't going to really matter at all.

The latter would take far longer, even if it were reliable. So not really; it'd need hardware support to be reliable, and if chipmakers are willing to do that, then they could implement hardware zeroing rather than require the OS to wait several seconds for charges to fully dissipate.

Hence this case where someone's porn was exposed from a previously-closed incognito mode session:

https://www.extremetech.com/computing/221208-nvidia-blames-a...

There's a nonzero risk there, but this seems like a relatively narrow problem that would be much trickier to exploit than any memory corruption bug.

It's also worthwhile pointing out that at the time MS were pushing Silverlight heavily, which provided GPU access through XNA and made itself accessible through a browser plugin by default.

MS's security side may have been against WebGL and the IE team either agreeing or using it as an excuse (and really, from this point of view, it doesn't matter!), but other parts of the company were exposing the web to the exact same problems.

The post specifically mentions that these things are not vulnerable to attack from WebGL, because you can't reach the APIs in question just by drawing.

The parts now exposed to WebGL are pretty well fuzzed at this point; much of the low-hanging fruit has now been picked.

Microsoft changed their minds and this article validates that the fears were mostly unfounded. Browsers can do enough validation of their own to mitigate most driver issues.

The same with sound.

Reply on news.ycombinator.com