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

[Mark Krenz <mark@xxxxxxxx>]

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.
   3.
    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 - bugtraq@xxxxxxxxxxxxxxxxx
o 2012-03-06 - climagic twitter account
o 2012-03-06 - Youtube video demo
o 2011-11-28 - Sent e-mail to behdad@xxxxxxxxxx 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