This document describes a method of reading and displaying previously used framebuffers from a variety of popular graphics cards. In all 4 tested laptops the content of the VRAM was not erased upon reboot. It is also possible to show that the content of the host VRAM can be accessed from a VirtualBox guest, thereby leaking possibly confidential information from a trusted host into an untrusted guest machine.
The discussion on hacker news provided some prior art
The following combinations of operating systems and drivers were tested and shown to be susceptible to leaking previous frame buffers into VRAM:
We did not test any other systems or drivers.
During testing, the following 4 cards proved to be susceptible to this method:
Note: The cards above are all the AMD and nVidia cards available at the time of testing. It is therefore highly likely that a lot more cards exhibit this behaviour.
On a laptop with an Intel HD4000 and a dedicated nVidia card where the OS can switch between cards, one has to force the usage of the dedicated card to read from VRAM. The internal graphics card seems to be unaffected at the moment. Tests showed that in this setup only programs forced to run on the dedicated card will leak data to VRAM.
The basic idea of the proof-of-concept code is remarkably simple: It allocates a number of texture buffers in VRAM without initializing them, then directly renders them onto the screen, thereby accessing previously used buffers.
The Code available here uses the SDL2 library.
In most Linux distributions it can be compiled using the following command:
g++ main.cpp -std=c++11 `pkg-config --libs --cflags sdl2` -o poc
The proof of concept executable excepts 3 arguments:
./poc <width> <height> <vram in megabytes>
The first two arguments represent the width and height of buffers that should be allocated. The last argument represents the amount of VRAM to be allocated. To avoid crashes, this should be slightly lower than the actually available VRAM.
After the buffers are allocated, they can be navigated by using the following keys:
The quality of the result seems to be dependent on the combination of the graphics hardware and the driver. Some combinations produce allmost perfect screenshots documenting user behaviour, while others produce fragmented frames with what seems to be interlacing. The example frames below demonstrate this effect. We are sure, that some math magic could help here.
3 out of 4 tested laptops did not erase or overwrite their VRAM upon reboot! This offers a potential attack surface for an attacker trying to read confidential information from a locked computer he has physical access to. A possible attack on a Windows-machine might look like this:
This scenario was tested on a Lenovo Thinkpad W500 with a ATI Radeon HD3750 graphics card. Below is a screenshot from within the Windows system, with a mock-up confidential document:
"screenshot" of the same document after rebooting into a Xubuntu live system and running the proof of concept code:
While the document is not entirely readable due to fragmentation and interlacing, the color coding shows us that the entirety of the screen might still be recoverable from VRAM. There are also clearly readable fragments.
Even 'the amnesiac icongnito live system' (tails) seems to be susceptible to this attack. Fragmented screens of a terminated tails session were recoverable after rebooting into a different operating system. This partially defeats the 'amnesiac' property of the system.
The following two screenshots document this experiment:
Oracle officially discourages enabling 3D-acceleration for untrusted guests - See their page on VirtualBox security here
If the "3D-Acceleration" feature of VirtualBox is activated, running the proof-of-concept code from inside the VM provides the ability to read framebuffers from the host system.
The following experiment was conducted to demonstrate this behaviour:
The following are interesting screens that where recovered using the proof of concept code:
The i3lock screen during password entry, containing some interesting artifacts:
Some textures recovered after a few rounds of counterstrike:source:
These are some additional screens we got via mail.
They show significantly less fragmentation.
Done with a nVidia GeForce GTX 560 Ti using the closed source driver.
It might be possible to leak the content of the VRAM of hardware-accelerated server systems that run thin client
infrastructures. In the scariest possible way this means that an attacker could read the memory of any machine running in a company.
This could also affect big players providing virtual desktops in the cloud.
As time and money are things we don't have in huge amounts, we were limited in our testing. Everything was done on a student budget in our free time.
The methods described in this document is not limited to a single vendor or operating system, and has the potential to endanger private data. Furthermore, the basic concept is so remarkably simple that it seems unlikely that this is the first discovery of this behaviour. Therefore, full disclosure seems to be the ethical choice.
If you use you computer to access sensitive data, TURN IT OFF after usage, so VRAM is disconnected
from power.
Be wary of virtual machines with access to hardware accelerated graphics.