html version with images available here: https://hsmr.cc/palinopsia # The Palinopsia Bug ## Is your VirtualBox reading your E-Mail? Reconstruction of FrameBuffers from VRAM 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. ## Affected drivers and operating systems The following combinations of operating systems and drivers were tested and shown to be susceptible to leaking previous frame buffers into VRAM: 1. Linux using the open source radeon driver for AMD/ATI cards 2. Linux usig the open source nouveau-driver for nVidia-cards 3. Linux using the closed source nVidia-driver 4. Windows using the closed source AMD/ATI catalyst driver We did not test any other systems or drivers. ## Cards affected During testing, the following 4 cards proved to be susceptible to this method: 1. ATI Radeon HD3750 2. ATI Radeon HD4350/4550 3. nVidia NVS 5400M 4. nVidia GeForce GT650M 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. ## Proof of Concept 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: https://hsmr.cc/palinopsia/main.cpp 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. ## What can be reconstructed? 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. ## Reboot 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: 1. The user works on a confidential document and locks their screen 2. The attacker gains physical access and reboots the system (from the lockscreen) into a live system of their choice 3. The attacker reads out the VRAM and recovers screenshots of the document 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: https://hsmr.cc/palinopsia/before/Capture.PNG "screenshot" of the same document after rebooting into a Xubuntu live system and running the proof of concept code: https://hsmr.cc/palinopsia/after/screenshot1.png 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. ## Tails 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: 1. booting into tails 2. generating an RSA private key and opening it in gedit 3. viewing parts of the private key in xubuntu after reboot https://hsmr.cc/palinopsia/tails/before.png https://hsmr.cc/palinopsia/tails/after.png ## Accessing host VRAM from inside a VirtualBox VM 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: 1. The host system (arch linux on a laptop running a ATI HD4350/4550 card) is booted 2. Wikipedia and Youtube are opened in Chromium 3. A VirtualBox VM running Ubuntu 14.04 is booted 4. The proof of concept code is executed. The recovered frames belong to the host system and clearly show the visited websites https://hsmr.cc/palinopsia/vm1.png https://hsmr.cc/palinopsia/vm2.png ## Gallery The following are interesting screens that where recovered using the proof of concept code: The i3lock screen during password entry, containing some interesting artifacts: https://hsmr.cc/palinopsia/gallery/i3lock.png Some textures recovered after a few rounds of counterstrike:source: https://hsmr.cc/palinopsia/gallery/cs.png ## What we didn't test 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. ### Disclaimer: 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. ## Why full disclosure? 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 disclore seems to be the ethical choice. ## Mitigation 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.