gnome-terminal, xfce4-terminal, terminator and others write scrollback buffer to disk

Title: Gnome terminal, xfce4-terminal, terminator and other libVTE based
terminals write scrollback buffer data to /tmp filesystem

Report date: 2011-03-06

Reported by: Mark Krenz

Severity: High depending on use and expectations

Software: libVTE v0.21.6 and later (since September 17th, 2009)

Copy of report available at:
http://www.climagic.com/bugreports/libvte-scrollback-written-to-disk.html

Affected software:

gnome-terminal
terminator
xfce4-terminal
guake
evilvte
lilyterm
sakura
termit
Anything else that uses libVTE for a terminal widget.

Summary:

Due to the way the history buffer is saved in terminal emulators
using libVTE after version 0.21.6, data from inside your terminal
window can end up on your local filesystem. This is most likely
unexpected behavior in a terminal emulator and represents a very
significant security issue.

Worse case scenario:

Classified, secret or medical information that was accessed through a
terminal window was thought to be safe because it was on a remote server
and only accessed via SSH, but now its also on the hard drive that is
for sale online or stolen without having been wiped because this
issue was not accounted for.

References:

http://ftp.gnome.org/pub/GNOME/sources/vte/0.21/vte-0.21.6.changes
https://bugzilla.gnome.org/show_bug.cgi?id=664611
https://bugzilla.gnome.org/show_bug.cgi?id=631685
https://bugzilla.xfce.org/show_bug.cgi?id=8183
https://plus.google.com/u/0/104947878052533251426/posts/Q9JmPiEckD9
http://www.climagic.com/bugreports/libvte-scrollback-written-to-disk.html

Video demonstration:

I felt that this problems caused by this flaw can't be stressed
enough and made a video demonstrating this problem. It can be viewed
at:

http://www.youtube.com/watch?v=LgNLHskYvVE

Description:

The libVTE library implements the virtual terminal widget that is used
by many widely used terminal emulators. This library handles how text is
displayed within the terminal and also handles how the scrollback buffer
is saved. On September 17th, 2009 a change was committed to libVTE by
Behdad Esfahbod that altered the way the scrollback buffer was
implemented in libVTE. The new way creates a file in the /tmp filesystem
and immediately unlinks it. This is not an uncommon way of handling tmp
files, however there are probably many people who would not expect
data from within the terminal window to be written to disk. There is
a sense of trust that the data in the terminal is only stored in memory
and is cleared when the computer is shut off. In a sense, this bug
is allowing the data to "break the forth wall".

I discovered this issue in November of 2011 while talking about uses for
the lsof command on the @climagic Twitter account. I immediately found
which software was the culprit and submitted a bug reports to Gnome's
Bugzilla. The response so far has been that the developer doesn't not
consider this a bug. I also wrote to Behdad Esfahbod about the issue
but have not heard back from him. I was giving these people a bit of
time to respond or resolve the issue, but apparently that isn't going to
happen without making a bigger deal of it. Other knowledgeable security
people have considered this a major security issue.

Daniel Gillmor brought this security issue up with the libvte
developer Behdad Esfahbod, in June of 2011 in bug #631685, but didn't
seem to convince Behdad that the code needed to be changed. Behdad
indicated at the time that he wasn't planning on working on libVTE in
the future. There have been a few posts in recent months in this bug
report about seeing if something can be done in the kernel, but the two
developers discussing it seem to be convinced that its OK to write this
data to disk.

Some may not consider this a bug and make the excuse that your
terminal's memory stack may end up in swap anyways, or that only root
would have access to the data or that you should encrypt /tmp. However
due to the wide variety of ways in which people implement security on
their systems, knowledge of this issue is essential to everyone who uses
one of these affected terminal emulators. With as much memory as we have
on modern hardware, some people simply turn off swap, which avoids the
stack in swap issue. But those people may not know about this scrollback
buffer issue.

Testing and reproducing the issue:

On Linux, if you want to see this behavior, you can do the following:

1. Open one of the affected terminal emulators.
2. Make sure its scrollback buffer is set to something like 500 or
   more so that it saves some of the scrollback.
3. In the terminal, run:
   ls -l /proc/$PPID/fd | grep deleted
   If enough data has entered the scrollback buffer, you should start
   to see unlinked (deleted) files called /tmp/vte.*

To see the data that has been logged to /tmp, you use a command like
strings to view the contents of your /tmp partition. If you have a
seperate /tmp partition and its located on /dev/sda2, this could be done
like this:

   strings /dev/sda2 | less

You should be able to search within that data for bits of information
like your username on remote machines or the remote hostname you
connected to and find data that was sent to the terminal from those
remote systems, which could include sensitive information like passwords,
logs, etc.

Recommended fix for users:

Use the following steps on any computer where you have used the
aforementioned software:

1. Use other terminal emulators that do not use libvte. I'd recommend
   urxvt, Eterm or xterm.
   Note: I do not recommend konsole because it has the same issue
   with writing scrollback buffer to disk. It encodes the data so
   it is not as visible, but it would be trivial to decode that data.
2. Backup your data on the filesystem where /tmp resides.

A. (separate /tmp) If you have a separate /tmp filesystem partition
   a. reboot into single user mode
   b. backup any data in /tmp to another location.
   c. unmount /tmp
   d. dd if=/dev/urandom of=<tmp partition device file>
     (run the above several times depending on your level of paranoia.)
   e. Remake your /tmp filesystem and remount.

B. (/tmp part of /) If you have a /tmp partition as part of your / partition.
   a. Backup all your data on the hard drive. Do not image the
      hard drive as this will preserve the data written to /tmp
      that we're trying to remove.
   b. Boot to a rescue OS like System Rescue CD.
   c. dd if=/dev/urandom of=<hard drive device file>
     (run the above several times depending on your level of paranoia.)
   d. Reinstall your OS.

4. Any data that you have accessed through your terminal using one
   of these programs should be considered breeched. Consider previous
   computers you have used and disposed of or sold, hard drives you've
   replaced, etc. They should also be wiped and any compromised data
   should be handled appropriately.

You could also use the shred command in place of dd in the previous
steps. Shred by default will overwrite a file 3 times with patterned
and random data.

If you want to continue using libvte based terminals, then I would suggest
that you look into using the tmpfs filesystem for /tmp as this will
put all of /tmp in memory and can be used transparently.

Don't try to fix the data breech issue by filling up the filesystem with a
large file and then overwriting it with 0s or using the shred command on it.
This will not work reliably due to filesystem implementations.

Recommended fix for developers and distribution implementors:

I'm not sure what can be done here since it has now been several
versions and years since that design change was made and the original
developer of the current implementation has stated that he doesn't
have plans to continue any work on it. If the current method remains
in place then I think a very strong warning should be placed next to
the scrollback buffer setting in the terminal emulator explaining that
data will end up on disk. The developer proposed plans to use an in
memory encryption key on the data on disk, which may be acceptable.

One motivation that seemed to drive the code change is that some people
want to have very large or even "unlimited" scrollback buffers. While
large scrollback buffers can be useful. if the need for an extremely
large scrollback buffer leads to the terminal becoming insecure, then
such a feature should probably be avoided. In my professional opinion,
security of the data in the terminal is paramount. By writing data to
disk in any way unknown to the end user, you are violating a trust
that users have had in terminals for decades. If you need a larger
scrollback buffer, then just install more memory on your host.

By writing scrollback data to disk, you're breaking any program
that relies on the data displayed in the terminal not being written to
disk, such as any console based password manager, gpg, encrypted volume,
etc. Their security practices become useless if the scrollback buffer
is written to disk in plain text.

Report history:

o 2012-03-06 - [email protected]
o 2012-03-06 - climagic twitter account
o 2012-03-06 - Youtube video demo
o 2011-11-28 - Sent e-mail to [email protected] asking about issue.
(never received response)
o 2011-11-23 - Posted notice of problem to climagic on twitter
o 2011-11-23 - Submitted bug report to libvte on Gnome's bugtraq
o 2011-11-23 - Submitted bug report to xfce terminal bugtraq

–
Mark S. Krenz
IT Director
Suso Technology Services, Inc.

Sent from Mutt using Linux