Message-ID: <550DF8DE.7040008@students.uni-marburg.de>
Date: Sun, 22 Mar 2015 00:03:58 +0100
From: Bastian <Reitemei@...dents.uni-marburg.de>
To: fulldisclosure@...lists.org
Subject: [FD] The Palinopsia Bug: Recovering framebuffers from VRAM

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.


Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists