Forgot your password?
typodupeerror
GNOME Security IT Linux

Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator 184

Posted by timothy
from the so-it-can-be-fixed-now dept.
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."
This discussion has been archived. No new comments can be posted.

Data Breach Flaw Found In Gnome-terminal, Xfce Terminal and Terminator

Comments Filter:
  • Skynet (Score:5, Funny)

    by Talderas (1212466) on Thursday March 08, 2012 @11:51AM (#39288559)

    We have a means to strike back at Skynet using this breach in the Terminator systems!

  • Shoot the VTE lib. Gimmie back my ASR 33.
  • by Anonymous Coward

    You have to be root (or the user who was running terminal in the first place) to see the scrollback data.

    So, how is this different than all of the hack-tastic things that root can already do?

    • by jesseck (942036) on Thursday March 08, 2012 @12:13PM (#39288935)

      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.

    • Surely you missed this part of the summary (you didn't even need to read the article):

      and can be viewed by anyone who gets ahold of your hard drive

      When dealing with real security needs, you might want to know if data only seen through SSH end up on your hard-drive.

      • Umm (Score:4, Interesting)

        by Viol8 (599362) on Thursday March 08, 2012 @12:25PM (#39289143)

        If someone has physically stolen your computer then the thief being able to read old terminal sessions is the least of your worries.

        • Re:Umm (Score:4, Insightful)

          by gzipped_tar (1151931) on Thursday March 08, 2012 @12:29PM (#39289209) Journal

          The problem is your terminal history may include data from other hosts, decrypted. Therefore it's not just "your" worries.

          • by X0563511 (793323)

            LUKS. LUKS. LUKS.

            Theft of a workstation or laptop drive should not threaten the rest of the network.

      • by allo (1728082)

        what about terminal-history in your swap-partition?

    • by fuzzyfuzzyfungus (1223518) on Thursday March 08, 2012 @12:15PM (#39288965) Journal
      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).
      • by Jerry (6400)

        ...'root' is anybody who mounts the HDD......

        IF someone has your HD then what's in /tmp is the least of your problems if you have secrets to hide.

    • by skids (119237) on Thursday March 08, 2012 @12:16PM (#39288977) Homepage

      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.

      • by Sipper (462582)

        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. T

  • Aterm seems to be ok.
    i don't see it listed as using libVTE

    http://packages.debian.org/wheezy/aterm [debian.org]

    • by lindi (634828)
      I might consider switching if aterm had at least support for clipboard (it only support X11 primary selection it seems, the one you access by pressing the middle mouse button. man aterm does not mention clipboard at all).
  • by Anonymous Coward

    This really sounds like how it was designed to work.

    Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.

    Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.

    • This really sounds like how it was designed to work.

      Thats what /tmp is for, after all, is it not? Sounds like the problem would be solved by partitioning different users data into seperate, appropriately secured /tmp files.

      Is bash history a "flaw" too? I'm sure plenty of people don't know that it's a text file anybody with access to it can read.

      Bash history is a different kind of threat; it's only about what command you used. Sure, you could get a few hostnames from it, but no more.
      Having your terminal session stored on disk mean that everything you see is suddenly on your filesystem, and staying on it if your /tmp is backed by the harddrive.

      • by Anonymous Coward

        Some people execute commands that take a password as a command line argument.

        Besides even that, you can learn a lot about a person from their .bash_history. More than just a few hostnames. You can make some inferences at least.

    • by skids (119237) on Thursday March 08, 2012 @12:20PM (#39289045) Homepage

      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.

  • tmpfs (Score:5, Insightful)

    by Sloppy (14984) on Thursday March 08, 2012 @12:05PM (#39288797) Homepage Journal

    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.

    • In some countries, it is illegal for you not to divulge the key to properly warranted authorities - even if you don't know what it is.
      • by X0563511 (793323)

        Then set up a keyfile for swap and edit /etc/crypttab appropriately. If you're doing the rest right, your encrypted root will protect the swap then, as well - yet you can comply with law enforcement and hand over the keys if ordered., yet still helps protect you from the thieves and other asswipes.

      • Re:tmpfs (Score:5, Informative)

        by Ceriel Nosforit (682174) on Thursday March 08, 2012 @02:23PM (#39290815)

        In some countries, it is illegal for you not to divulge the key to properly warranted authorities - even if you don't know what it is.

        So what? In my country blasphemy is illegal. I'm not from the Middle East either, I'm a Finn. - Sometimes you just have to, grow a backbone, fuck Jesus in the ass and break the law.

    • On a memory-limited system, one may not want /tmp kept as tmpfs in the RAM.

      • by dalias (1978986)
        It's not kept in ram. It's kept in virtual memory. Which might or might not be present in ram at any given time. Pretty much the same as data on the filesystem, which also might or might not be kept in ram at any given time.
      • My N900 with only a quarter-gig RAM uses tmpfs and it doesn't cause any trouble.

    • by Anonymous Coward

      Encrypt swap? Who the hell uses swap these days?

      Lets says you have a mere 4GB of RAM. A small swap file of say 512MB would be useless considering how much you already have but if you go to 1GB+ size swap files then your machine is going to grind to a halt (ie. become useless) if you start swapping that much memory.

      Swap is useless and/or pointless if you have 2GB or more of RAM.

      • by allo (1728082)

        why? When processes get bigger and harddrives get faster, the swapfiles can grow as well.

        • by MrNemesis (587188)

          Swap files may grow, but the speed of hard drives doesn't scale along with everything else. Take a good platter-based drive and you're lucky to see reads/writes of 20MB/s assuming little to no HDD contention, especially since swap is typically highly random non-sequential 4k access. RAID that up or us an SSD and you might get 50MB/s. Lets say you have a 512MB swap, as I do, it'll take 10s to read the whole thing. Take a 512GB swap (like one poor server I found at work - someone was following the appallingly

          • by gottabeme (590848)

            > Stick with a small swap file and not much crap ever gets written to disc, saving you the horror of having to reset a server for the umpteenth time when it's been grinding on its system disc for five minutes trying to page in the OOM killer.

            Great theory, but in reality it would hit the OOMk too often and random processes would die too often. Hey, I've suffered swap-of-doom plenty of times, so I know what you mean and feel the pain--but the alternative is worse.

            What really does help is zramswap. Makes

      • by Rashkae (59673)

        *Sigh*, this again. No matter how much memory you have, some of it will end up with accumulated cruft that rarely needs to be read/changed. That ram would be better used freed up (swapped out) and used for cache instead. And 2 GB is nothing compared to a modern Desktop (gnome, Unity, KDE, take your pic.) If you do any kind of multitaking of large applications, you need a minimum of 8GB before you can be safely swap free.

        • by izomiac (815208)
          Linux is certainly getting more bloated, but the last I checked my whole system volume could easily fit into 4 GB of RAM with enough room left over for standard desktop usage. Caching data files is nice, but with an SSD that shouldn't be noticeable, nor does it work if you're unlikely to reopen files. Obviously, different usage patterns have different requirements, but, for me, the only time I hit my RAM limit in any OS is with a memory leak (Firefox -- which happens daily if I let it). Not swapping shou
          • by gottabeme (590848)

            It fits at first--but after a day or two it doesn't. Then you have to restart X, or at least log out/in.

      • by gottabeme (590848)

        Do you even run X? I have systems with 3 and 4 GB of RAM and they still end up sucking up more and more RAM and swapping stuff out if I have a long enough X session and use a modern web browser. If I had 2 GB and no swap I'd hit the OOM killer every few days at least.

      • by Sloppy (14984)

        Swapping to read files from tmpfs is going to grind slower than using a disk filesystem for /tmp? I guess it's time to do some benchmarks because if it's true, I'd call that a tmpfs bug.

        People are telling me don't use disk because it's too slow, but don't use ramdisks because their computer doesn't have enough RAM. The only thing people can agree on, is that I'm wrong.

    • by couchslug (175151)

      "(you don't even need to know a key to be coerced from you)"

      Great. That just means a longer beating from the proverbial XKCD Crescent wrench....

    • by mrmeval (662166)

      I shall look but you seem to know how to setup and configure to use tmpfs for /tmp. I'm using LXDE and they use tmpfs for some things but I'm unsure if /tmp exists there. Thanks.

  • This guy, right [behdad.org]?

    Interesting choice of inspirational quote:

    It is amazing what you can accomplish if you do not care who gets the credit. - Harry S Truman

    The same applies to blame, Behdad.

  • Not a bug (Score:5, Insightful)

    by Anonymous Coward on Thursday March 08, 2012 @12:10PM (#39288873)

    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.

  • by WatchMaster (613677) on Thursday March 08, 2012 @12:14PM (#39288947)

    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.

    • ... or just don't use swap. It's not like you need it any more. I'm running with no swap partition, no swap file, and even with openoffice and eclipse and firefox and opera open, I still use less than a gig of ram.

      Of course, I also close firefox every day - it leaks memory.

    • by suso (153703) * on Thursday March 08, 2012 @12:31PM (#39289243) Homepage Journal

      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.

    • From TFA:

      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.

      • by zeldor (180716)

        It looks like only if the scrollback size is unlimited or at least really huge.
        I have 1000 line scroll back and konsole creates no such files in /tmp.

  • ... contains lots of stuff much worse than scrollback buffers should some nefarious character manage to lay hands on it.

    Aside from that, any /tmp (physical or volatile) can be a problem on a multiuser system if the app is dumb enough to create files with go+r permissions. If this isn't done, those files are as secure as any in my home directory.

  • by Mysticalfruit (533341) on Thursday March 08, 2012 @12:22PM (#39289093) Journal
    considering how much /tmp gets used, having it in memory is one of the quickest ways to boost the performance of your system...
    • With all the layers of caching between an application and the spinning drive, isn't /tmp (and every other filesystem) essentially in-memory anyway (at least for short-lived files)?

      • by Anonymous Coward

        No. This is one of the more common misconceptions.

        tmpfs is an entire filesystem in memory. It stores objects directly in memory. It is MUCH MUCH faster than a regular filesystem because its metadata keeping is much cleaner, simpler, and it is hot-cache-aware. This is speedup 1.

        tmpfs does not have a backing store device other than swap, while a normal filesystem does. A normal filesystem HAS to evict dirty pages and metadata to the backing store, even if you created and destroyed a file before the write

    • by evilviper (135110)

      I benchmarked this about a year ago on a couple RHEL5 servers. A particular application wrote out a few MBytes of tmp files everytime the application was asked to sort some data... which was so often we were talking hundreds of megabytes... vastly more IO than /tmp on a normal system would ever see.

      Anyhow, long story short, moving /tmp to tmpfs (RAM) made absolutely no performance improvement at all. In fact it was a small slowdown... I assumed this was because it was pushing some buffers/cache out of p

  • by Viol8 (599362) on Thursday March 08, 2012 @12:32PM (#39289255)

    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.

    • Shell history doesn't contains only input, not output.
      Someone may have splashed some GPG private keys to the terminal, and the output ends up in the filesystem blocks.

      • by truedfx (802492)
        Aside from that, shell history doesn't contain anything not entered into the shell. Particularly, it doesn't contain anything entered into another remote shell.
    • by Dcnjoe60 (682885)

      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.

      It might not be a high risk issue, but it probably should still be fixed.

  • Nothing to see here, and moving on .. so you have access to the tmp directory which may have a record of what you viewed during the session ...
  • Does this impact KDE's Konsole, too?

  • Now get of my lawn!
  • by DarkOx (621550) on Thursday March 08, 2012 @01:28PM (#39289959) Journal

    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!

  • Seriously. Disable scrollback and use screen. You're life will improve.
  • ..that you once owned, you have a much bigger problem than your scrollback buffer.

    AES-NI makes encryption almost free. There's no reason not to use it.
  • This is truly a non-issue. If your machine has swap, then ANYTHING in memory can end up on the disk. The data is not exposed in a way that it can be grabbed by other users, you would have to dig through the disk image to find the unlinked file.

    Very simply, if you ever dispose of or sell a hard drive, you MUST wipe it first. If a drive fails and you want to make sure no data gets out when you throw it away, you must destroy the platters.

    SSH has nothing to do with this. It is not and never was a magic faery w

  • by Zoxed (676559) on Thursday March 08, 2012 @03:56PM (#39292401) Homepage

    Yet another reason to use a VT100 hooked up to the serial port !

  • This is how you should implement unlimited scrollback, create a tmp file in /tmp and then unlink it so it will be freed on exit.

    /tmp is something a sysadmin should be aware of. All kinds of sensitive data is written there by applications and if the computer might be stolen and contains sensitive information then /tmp and swap (and a few other things) should be encrypted or otherwise secured. But honestly if someone with malicious intent gets physical access to an unencrypted disk I'm sure they wouldn't eve

    • He is mounting "/dev/sdb1" to "/tmp". Most Linux systems mount the in-memory only "tmpfs" to "/tmp", so data written to it is in memory only. Unless the pages comprising "tmpfs" are swapped to disk, none of this information should ever even touch the hard disk. But the way he set it up, "/dev/sdb1" will capture all terminal data. Why would you even set it up this way to begin with? It's not the default setup.

      This is pretty stupid. Not a security vunerability, just another thing to be careful of -- never mou

      • by suso (153703) *

        These claims are actually not true. Results that show otherwise forthcoming.

  • The point is that this data should never have hit the disk in the first place. The screen is expected to be an ephemeral medium--not one recorded to disk automatically. How would you feel if you discovered that ffmpeg was recording your entire screen to /tmp/username.mpg without your knowledge? Sure, clear your browser cache and history and vacuum the dbs--but then all I need to do is find the stream of your desktop session video and play it back, and I'll be able to see most of what you did, even though

Some people have a great ambition: to build something that will last, at least until they've finished building it.

Working...