Hacker News Reader

Comment by sudont | Hacker News Reader

I assume there's probably a risk of arbitrary code execution, which is mostly mitigated by vetting each ad. Too bad though, would be nice to see what could be built for iOS web apps.

View on HN

I'd love to know what the imagined risk would be - as far as I can see the only additional capability from WebGL against regular JavaScript is to send commands and data to and from the GPU. What harm can that do?

There are a few issues here. One is that bugs in the GPU itself can enable memory corruption (and thus code execution), and the other is that GPU drivers are notoriously buggy and huge, making a large attack surface. I can't blame them for being concerned in this case -- opening the GPU to web developers at large opens up a huge can of worms.

I hope that Apple has enough clout with their GPU providers to get them to fix their driver bugs and implement ARB_Robustness. Seriously if someone can get a good and safe implementation of WebGL it's apple. They own the hardware and the software.

the GPU isn't a safe place to execute code. code running on it can be written to hijack the system, thereby providing an entry point for viruses etc.

even on chrome the webgl support is limited to specific gpus that have been vetted by the devs.

It's not really the GPUs that are the issue (once it's on the GPU I don't as far as I know see a way to hijack the system) it's the drivers that are the problem. Before your shaders can run on the GPU they have to be compiled and it's that that funny stuff can occur I believe. I guess you could maybe find a way to interfere with the other applications using the GPU for rendering.

Hopefully someone here as a good understanding of this stuff and can tell me if I understand the risk wrong.

once it's on the GPU I don't as far as I know see a way to hijack the system

I think GPUs can do DMA => If you can break into a GPU, you may be able to write into kernel space, just like you could (can?) break into a Mac over it's FireWire port (and, possibly, the Thunderbolt port in new MacBooks)

GPUs don't respect CPU memory protection -- they can write to any region of mapped memory. If you happen to have some of your program code living there you can "draw" over it with replacement code.

What you wrote doesn't make any sense whatsoever, you seem to imply that there is an inherent problem by design with this, but there is no such thing. There are possible bugs etc. that could lead to arbitrary code execution by exploiting as-yet-not-found holes in current drivers. But saying that you can draw over program code would allow even browser content to overwrite program code, especially in these days of GPU accelerated browsers.

To be fair, it's possible for the GPU to write to arbitrary memory, but it wouldn't happen as a matter of standard usage by any means.

It's only a problem if the bits of memory you want to enforce special protection rights on (ie: no execute, read only, etc.) is also mapped into the GPU's address space.

It's not something that "just happens" normally, it most often requires clear intent to do so, but it can be done.

Microsoft considers WebGL potentially harmful:

http://blogs.technet.com/b/srd/archive/2011/06/16/webgl-cons...

It goes without saying MS has its own agenda regarding web technologies, but the risks are there.

It all depends on the implementation though, right? If Safari just does a simple check to see if the source URL is something like http://adserver.apple.com then it would be trivial to hack DNS and send WebGL to your iOS device.

I can definitely see this being an attack vector used by jailbreakers to jailbreak iOS 5. I think the only way they could prevent these type of DNS jacking attacks is to use a trusted SSL certificate on their iAd servers. I'm not sure what type of performance penalty that would add, forcing all advertising traffic to use SSL.

Reply on news.ycombinator.com