Slashdot Mirror
Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator
suso writes "A design flaw in the VTE library was published this week. The VTE library provides the terminal widget and manages the scrollback buffer in many popular terminal emulators including gnome-terminal, xfce4-terminal, terminator and guake. Due to this flaw, your scrollback buffer ends up on your /tmp filesystem over time and can be viewed by anyone who gets ahold of your hard drive. Including data passed back through an SSH connection. A demonstration video was also made to make the problem more obvious. Anyone using these terminals or others based on libVTE should be aware of this issue as it even writes data passed back through an SSH connection to your local disk. Instructions are also included for how to properly deal with the leaked data on your hard drive. You are either encouraged to switch terminals and/or start using tmpfs for your /tmp partition until the library is fixed."
We have a means to strike back at Skynet using this breach in the Terminator systems!
"Lack of speed can be overcome. In the worst case by patience." --Znork
Once you go tmpfs, why would you ever go back, VTE flaws or not? tmpfs kicks ass.
Then encrypt your swap (random key every boot; you don't even need to know a key to be coerced from you) and you have a safe /tmp.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is not a bug. This is exactly how /tmp is meant to be used. It is no different from sensitive data from your internet cache being stored on the hard drive.
If your garbage data is sensitive, you should encrypt /tmp, or mount a tmpfs there.
While the system is running, yes, you either need to be root or run an exploit which escalates your privileges so you can see the temp file. When the disk is removed from the system you don't need to be root to read the files. Nor would you need to be root if you booted from a LiveCD.
This is true of vi and many other programs. The exact same issue occurs with the swap partition.
Anyone can solve this problem, just mount /tmp and swap using dm-crypt with a new random password every reboot. The partitions are perfectly good while the computer is booted, but are inintelligible afterwards.
If you are using a persistent /tmp, 'root' is anybody who mounts the HDD...
Now, if you want scrollback data to be persistent across reboots, you have to suck it up and dump it to disk somewhere(user home might be a slightly better idea, since support for encrypting your home directory is slightly easier than for encrypting the entire disk); but if that isn't a requirement you probably don't want it touching the disk at all(unless you are in a very memory constrained and swapless environment where getting OOM killed every time something unexpectedly verbose happens would be really annoying).
It's a particular problem if you A) don't run on entirely encrypted partitions, and B) have your kit stolen or get rooted. Your biggest problem is that you had your kit stolen or got rooted, however, this problem effects the damage control process.
Usually when you have a compromise you assume that only data that is "on the host" is compromised, and any data from other hosts is only compromised if it happened to be viewed after you got rooted (because the attacker could have been keylogging.) With cleartext from encrypted sessions hitting disk, this means that data could be sitting around in unused block in /tmp for years, so once you get rooted you have to assume everything ever done on other machines using a terminal on that machine has been exposed. So if you edited your corporate HQ's VPN PSK 2 years ago, that may still be on your disk.
tmp is less likely to be on an encrypted media than other filesystems, because it is usually expected to be a performance bottleneck.
The good news is that in many cases the data never got flushed back to disk and stayed in the filesystem buffers, but for high security concerns this is little consolation.
Someone had to do it.
People in the know know about cli history files. They don't necessarily expect data viewed in a terminal window to hit disk. It may or may not be a "flaw" depending on your opinion as to what appropriate security measures amount to, but it's worth an awareness campaign.
Someone had to do it.
considering how much /tmp gets used, having it in memory is one of the quickest ways to boost the performance of your system...
Yes Francis, the world has gone crazy.
If someone has physically stolen your computer then the thief being able to read old terminal sessions is the least of your worries.
I haven't had time to look into it completely, but when you have konsole set to unlimited scrollback mode, it will create files in /tmp/kde-username/konsole*.tmp that have your scrollback buffer. It is encoded somehow, but its there. I'm not sure if its encrypted or not. I found out about it because when I talked with the libvte developer (Behdad), he said that he looked at the code in Konsole to see how they did it before writing the implementation in libvte.
Various shells store command history as a .[shell name]_history file in the users home directory which can be left between sessions. Thats happened for years and root can view that too.
Sure, this may be a bug but frankly its a non issue.
That would be in your .bash_history file (or whatever you name it locally).
Really, this is way overblown by calling it a "data breach": it's not as if your data is compromised to a remote attacker. It requires that somebody else has your disk. As we all know, if your hardware is stolen/confiscated/impounded/seized/whatever, only encryption can keep your data safe. Apparently, even that can be circumvented by legal compulsion.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
If I were the author of this library I'd be a little annoyed. The article is written as if the library does something wrong. It does not. It stores data on /tmp, which is there to be used as scratch space. To read the file you have to be the owner or root, which has been true of every process that has written there since before my years. This is perfect correct.
Okay some uses might not expected their terminal emulator to keep temporary files. Yes if your disk is appropriated someone not root in your environment might be able to read it. Which is true of basically any process that writes anything to disk anywhere; even ones that don't. Suppose my system is under enough VM pressure that my good old fashion xterm gets paged out? Why scroll back buffer data, which might even have come from SSH would be right there on my disk! OH! NOS!
If you are dealing with a system that is physically insecure, like a laptop, or machine in a public spot, or information that is so sensitive you'd be more concerned about it being out there than the fact that your hard disk or entire system has gone missing; there is a solution for that. Its called disk encryption! If you use Linux it won't even cost you anything!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Anonymous Coward,
You may want to read the end of this comment before jumping to conclusions:
https://bugzilla.gnome.org/show_bug.cgi?id=664611#c10
Ie. I offered to fix it, before the report was published. And the report is deliberately misinformed to make it look like I said I don't have any intention to fix it. And the report author tweetted [1] "Apparently not a lot of people read Slashdot anymore or RTFA. I've only had 971 hits to the article so far. :-(", which makes me believe that his true intention was to get Slashdot / Reddit / Hacker News bragging rights. Comes handy if you are a sysadmin I guess...
behdad
[1] https://twitter.com/#!/climagic/status/177796284755873793