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."
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.
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.
The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.
Colorless green Cthulhu waits dreaming furiously.
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