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
Aterm seems to be ok.
i don't see it listed as using libVTE
http://packages.debian.org/wheezy/aterm
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.
When dealing with real security needs, you might want to know if data only seen through SSH end up on your hard-drive.
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
Seriously. Disable scrollback and use screen. You're life will improve.
It looks like only if the scrollback size is unlimited or at least really huge. /tmp.
I have 1000 line scroll back and konsole creates no such files in
If I could walk that way I wouldnt need cologne.
what about terminal-history in your swap-partition?
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
Yet another reason to use a VT100 hooked up to the serial port !
I opened this bug back in 2011: https://bugs.launchpad.net/ubuntu/+source/vte/+bug/778872 I've also fixed it now. See the patch: https://bugs.launchpad.net/ubuntu/+source/vte/+bug/778872/+attachment/2836456/+files/stream-mem.patch
Very much in agreement, but in some instances there are additional features that further mitigate this at least in the long-term.
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.
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one. But also last I knew, other systems don't. Someone had reported about a year ago that Fedora didn't do this, for instance. It came up because the poor guy was using a Debian-based box and had copied his entire home directory into /tmp, rebooted, and expected to copy it back. Oops. That got into discussion of which systems erased /tmp and which didn't.
Additionally I've found that some newer Linux kernels in the 3.x series (at least 3.2) seem to mount /tmp as a tiny tmpfs filesystem, rather than using the root filesystem. [I've checked, and this is not something done in /etc/fstab. There's a tiny chance this might be something done via the initrd image, though.] tmpfs is still backed by swap, however.
One piece of good news is that some systems erase /tmp on startup. Debian does this, for one.
Yes and no... Debian (and most other systems, I might add) only deletes the files/dirs that are still present on the filesystem (i.e. what "find" can find on /tmp). It doesn't try to securely wipe those data blocks or the data blocks that wasn't part of any of those files.
Damn good point. I stand corrected.
The last part is important, cause in the case of libvte, the file is open()'ed, then unlink()'ed right away, thereby no longer showing up on the filesystem even though the file is still in-use. The close() won't happen until the terminal is closed. In other words: As the file is no longer present on the filesystem, it won't be deleted (again) from /tmp and the data blocks won't be wipe. Therefore the old data will still be present on the disk even after a reboot.
I think you're right. :-/
You could probably change the boot script to use a more secure wipe of the files it's deleting, but that still won't help you in this case as the file in question was already delete long before the reboot. A complete wipe of /tmp's device won't be a good idea either, unless you're absolutely sure /tmp is on its own device, i.e. if /tmp is just an ordinary dir on /, you don't want to wipe all of / on boot up.
I suppose one option would be a "secure wipe on free space" via the sfill command from the secure-delete package on the filesystem that /tmp is mounted on.
IIRC at some point certain filesystems had a flag to set for a "secure delete" option, which would fill files erased with zeros when a file link count reached zero, but I don't recall whether any of these were actually implemented.