Hacker News Reader

Comment by Eridrus | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com