16

Today, almost all desktop and most mobile operating systems and devices support some version of OpenGL. I'm wondering about the security implications of that:

  • In many cases, the GPU has complete and unrestricted access to the main memory (for integrated graphic devices) or at least the video RAM, where sensitive information might also be stored (think compositing window managers or hardware-accelerated web browsers).
  • In some implementations, OpenGL clients communicate with the GPU by directly writing data and commands to shared memory.
  • Only recent GPUs seem to support memory virtualization, and even then, only some driver implementations are currently using it.
  • WebGL requires newly allocated buffer objects to be zero-initialized; I suspect that this means that this is not required in standard OpenGL. Does that mean that it is theoretically possible to allocate a buffer in video memory and read potentially security sensitive data?

So who or what keeps me from writing a shader program that reads data in the video or even main memory that doesn't belong to me?

I've found a presentation on the current state of affairs in the Linux graphics system which mentions that either the commands to the GPU are verified by the kernel, or that virtual memory is used on the GPU to separate users.

Is that also true for other, especially mobile, operating systems like Android, where the individual applications are strongly sandboxed, but have almost unlimited OpenGL access? Tegra 2 is even specifically mentioned in that presentation for allowing potentially unlimited memory access to users of the driver.

lxgr
  • 4,094
  • 3
  • 28
  • 37
  • Good question, it extends to all DMA hardware - pretty much anything that plugs into a PCI slot or Firewire port, which then runs software (or even just firmware) that could be subverted. – lynks May 09 '13 at 15:38
  • @lynks Lots of PCI devices do not have DMA access if the operating system has not set the bus master bit in the control register of the PCI configuration space. The PCI device cannot modify the bit (even though it is stored internally in the PCI registers, I think because it's shadowed by the PCH), so many devices are harmless. You can use lspci to see if bus master is enabled. – forest Feb 01 '18 at 05:50

2 Answers2

8

I've performed a few experiments on Linux and various GPUs and drivers. I took a basic OpenGL tutorial for texture mapping and replaced the pointer to the texture data in the call to glTexImage2D with a null pointer.

With the nouveau driver on an Nvidia GPU, the results were pretty interesting:

Uninitialized OpenGL buffers using nouveau

The text on the cube seems to contain the previous contents of my terminal window, which is composited on the GPU by Compiz.

The Intel GMA driver showed only a black cube; it was the same on Android (tested with an Adreno and an Nvidia Tegra 3 GPU).

Of course that doesn't prove that either of those drivers/systems are safe; the OpenGL implementations might just as well initialize the memory only in the userspace component of the driver instead of in the kernel.

lxgr
  • 4,094
  • 3
  • 28
  • 37
3

For proper security, graphic cards must be treated like all other sorts of hardware which have access to RAM: they must come under the umbrella of the MMU and the kernel-controlled scheduler, so that simultaneously executing tasks cannot impact each other, and may interact only through communication channels carefully managed by the kernel.

As you note, such isolation and sharing for 3D graphic controllers is only a recent feature. For most of the two previous decades, accelerated 3D graphics have been an open road to vulnerabilities... which turned out to be only very rarely exploited, for the following reasons:

  • On most systems (Windows, Linux...), access to the 3D card is authorized only to users who sit in front of the machine, on the basis that smooth 3D animation just don't cut it over the network anyway. Evil people who have physical access to the machine have much more efficient entry pathways into the system than fiddling with the GPU.

  • Dealing with low-level details of GPU is hard work, especially since a lot of them are not documented (which is why proprietary drivers are still used in Linux). Attackers are also human beings, hence inherently lazy.

Sandboxing platforms like smartphones may change that, because they do host applications which can access the 3D hardware and yet be hostile to each other. But why would they care ? It is so much simpler to ask for extensive access rights upon installation (the user just says yes to all anyway).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Very interesting - I knew that it was hard to access the GPU over remote login sessions, but never suspected the reason was security... I also mostly agree with respect to exploiting the GPU being harder than exploiting user carelessness, but still, there is an important distinction - cautious users CAN verify the permissions before installing, but there is no permission for OpenGL. – lxgr May 10 '13 at 08:48
  • The DRM subsystem is the same regardless of what driver is in use, so a vulnerability in it could be driver-independent, requiring no knowledge of the low-level details of any individual GPU. – forest Mar 31 '18 at 05:21