Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator 184
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."
tmpfs (Score:5, Insightful)
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.
Not a bug (Score:5, Insightful)
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.
Re:Doesn't sound like a flaw to me (Score:4, Insightful)
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.
Re:Umm (Score:4, Insightful)
The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.
How is this is this different to shell history? (Score:4, Insightful)
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.
Overblown (Score:5, Insightful)
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.
I'd be a little miffed (Score:5, Insightful)
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!
Re:Overblown (Score:2, Insightful)
So on a running system (using LUKS or not), any user that has read-permissions on the block device (members of i.e. group disk) containing /tmp will be able to see all other user's input? how sweet! And why delete them? A process that uses a file to write data, will keep using this space until closed anyway, so you might as well just show they're actually there taking up space? Or is there something in these files that isn't supposed to be easily seen? oh wait.
This is not only a risk for offline filesystems (when the disks are yanked out), but also for running systems with multiple users (i.e. using freenx, x2go, etc). While fully admitting my complete and utter inability to program sh*t, I do feel this is to be considered a grave security issue, not even .