This is why I'm absolutely terrible at security considerations. When I look at webGL, I think what's the problem? So what if you have direct access to the GPU?
My naive view of the graphic card is:
shader instructions -> VIDEO CARD -> PIXEL DATA
Shader instructions are a limited to a specified function set directed at transforming and calculating numbers. What possible risk can a calculator represent?
Video Card is a hardware device that simply implements the calculator language. It only has access to the numbers and data it was supplied. It crunches the numbers, and then returns pixel data. The video card is a black box, numbers go in, numbers come out.
Pixel data is just a set of numbers that represent color. You take the pixel data and you send it to the monitor.
Honestly, what could possibly go wrong?
Seriously, I have a hard time comprehending the "surface" are of the attack. I'm familiar with ideas like memory buffer overflow attacks--but I mean video cards have their own dedicated memory, even if you manage to read some memory outside of your allocated block--you'd only be getting numbers from the video card memory which is just geometry definitions...
Actually, just now typing that last paragraph I think I figured out why gaining access to the GPU memory would represent a security concern. I suppose if that memory contained screen pixel data, it could be used to "read" what was on the screen via some form of OCR? Or, perhaps maybe depending on the OS implementation, more than just "pixel" data may reside in the GPU memory.
Gr, it's really quite frustrating that these stupid security issues keep getting in the way of forward progress--or more so that large company vendors are back pedaling simply because it's a "hard" problem to tackle.
I saw that this story link was really just a recap of an original source (which appears to be down for maintainance now). The original source linked to these two papers, which upon a quick read had some content that I wasn't familiar with, so thought it might be news to others too.
In general, when I see blog recaps I almost always go to the source. This blog entry, like most good ones, will link to their sources.
I wish I could say it was because I'm an expert on OpenGl and security. I'm really just a rabid link follower.
The biggest issue is that GPUs can do DMA to read and write directly in main RAM. This can be exploited to overwrite arbitrary kernel data structures, for example.
But before the code gets to the GPU it has to be compiled and that's the job of the GPU drivers which are know to crash often. Video card drivers are the problem. If you can manage to make them crash in a predictable way then you have a way to crash the machine and I guess reboot the box on windows. Who would have thought that a small program to do graphics manipulation could be used to reboot a box? I mean something is wrong here on many levels.
My WebGL app has frozen a few machines in the past with random bugs that I haven't figured out yet. I tell my users to be careful but I know someone out there knows how to do it predictably.
But you know what, it's about time Nvidia/ATI/Intel/others pull their own weight and fix the damn issues with their drivers. If it can be done with WebGL it can be done with native applications. Flash Molehill probably too.
I'd be more worried that the drivers run in kernel mode and this could actually allow a new class of root-level arbitrary code execution vulnerabilities.
That's definitively an issue. Is there a way around graphic drivers in the kernel? Userspace graphics drivers could be interesting if they were possible.
You're definitely correct about Windows (it was something I was excited about in Vista), but I'm not sure about Linux. Looking at the Nvidia GLX drivers for my Linux machine, it still seems like quite a hefty kernel module. I can't really examine it, though, because it's not open source.
Actually the part of it that runs in kernel mode does have it's source visible. It's part of the standard packaging provided by NVIDIA so that it can work on many different kernel versions. For the most part their driver is also userspace and the kernel driver exposes a communications pathway to the userspace. That's not to say I know how robust that pathway is, but they have separated things somewhat.
The open source drivers also follow this kind of model where the kernel modules handle hardware access and memory management but not a whole lot more. Mesa (and Gallium 3D) all work in userspace to handle compiling things to the native formats of the cards.
User space drivers are possible, the problem is efficiency nosedives. The premise of microkernels[1] is that the kernel itself is "trivially" small and everything else runs as a userspace task.
>it's about time Nvidia/ATI/Intel/others pull their own weight and fix the damn issues with their drivers
It's been about time for 15 years, and they still haven't. Video card drivers are #1 reason for windows crashes. Microsoft put a lot of pressure on these companies (and Microsoft knows pressure) and it still didn't help.
Here common sense applies, if you are going to use financial services just use them. Visit WebGL sites when you are not doing something serious and problem solved. Also while it is technically possible to do, it is really difficult to exploit, I program GPUs.
I understand Microsoft position here too, they don't want people suing them because someone manage to get their financial data and stole their identity and money while watching cool webGL animations, but I think you can trust the big guys (google) on this one, they are not going to steal your financial data, in some cases they already have it :-).
I think their concern is that the hardware drivers have bugs in them that could lead to remote compromise, not that access to the GPU. Microsoft knows something about this, as the execution of untrusted/unsigned shader code allowed the Xbox 360 to run unsigned code back in the day: http://en.wikipedia.org/wiki/Free60
My naive view of the graphic card is: shader instructions -> VIDEO CARD -> PIXEL DATA
Shader instructions are a limited to a specified function set directed at transforming and calculating numbers. What possible risk can a calculator represent?
Video Card is a hardware device that simply implements the calculator language. It only has access to the numbers and data it was supplied. It crunches the numbers, and then returns pixel data. The video card is a black box, numbers go in, numbers come out.
Pixel data is just a set of numbers that represent color. You take the pixel data and you send it to the monitor.
Honestly, what could possibly go wrong?
Seriously, I have a hard time comprehending the "surface" are of the attack. I'm familiar with ideas like memory buffer overflow attacks--but I mean video cards have their own dedicated memory, even if you manage to read some memory outside of your allocated block--you'd only be getting numbers from the video card memory which is just geometry definitions...
Actually, just now typing that last paragraph I think I figured out why gaining access to the GPU memory would represent a security concern. I suppose if that memory contained screen pixel data, it could be used to "read" what was on the screen via some form of OCR? Or, perhaps maybe depending on the OS implementation, more than just "pixel" data may reside in the GPU memory.
Gr, it's really quite frustrating that these stupid security issues keep getting in the way of forward progress--or more so that large company vendors are back pedaling simply because it's a "hard" problem to tackle.