Go back to climagic home page

Bugreport - libVTE scrollback buffer written to disk, affecting gnome-terminal, xfce4-terminal, terminator and more.

Title: Gnome terminal, xfce4-terminal, terminator and other libVTE based terminals write scrollback buffer data to /tmp filesystem Report date: 2012-03-06 Updated: 2013-05-14 Reported by: Mark Krenz [mark@suso.com] 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 terminal's scrollback history buffer (not shell command history) 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 it's 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 (temporary blocked read/write access to anonymous views of this bug) 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 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 it's 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 it's 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 separate /tmp partition and it's 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.

History of issue:

Related:

Created: 2012-03-06; Updated: 2017-10-01

Please enable JavaScript to view the comments powered by Disqus.

Disqus