Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
GNOME Security IT Linux

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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • 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.

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

  • 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 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 suso ( 153703 ) * on Thursday March 08, 2012 @12:31PM (#39289243) 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.

  • by Anonymous Coward on Thursday March 08, 2012 @01:44PM (#39290195)

    Just take a look at what the GNOME developers call "community relations" these days:

    https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org]

    The very first person that tries to protest the lack of response by the VTE developers gets his account disabled immediately. And people wonder why GNOME 3 is such a clusterfuck, it's full of people like Behdad.

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

  • Re:Overblown (Score:5, Informative)

    by behdad ( 320171 ) <slashdot@be[ ]d.org ['hda' in gap]> on Thursday March 08, 2012 @02:28PM (#39290913) Homepage

    That's misinformed. Vte creates files in /tmp, and immediately delete them. So, the space will be reclaimed as soon as the terminal tab in question is closed. I know this is how it works, because that's how I wrote it.

  • Re:Umm (Score:5, Informative)

    by behdad ( 320171 ) <slashdot@be[ ]d.org ['hda' in gap]> on Thursday March 08, 2012 @02:55PM (#39291429) Homepage

    You have to read the bugzilla report carefully to see what this story is about. I'm the developer being [bf]lamed. I offered to find time on a weekend and fix the issue. But the reporter ignored my offer and went ahead to post this on as many places as it could. In the report, he masks that, and instead says I don't consider it a bug. The report is intentionally written misinformed IMO. Which makes me think the true story is that he wanted to get some publicity...

  • 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 [gnome.org]

    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 [twitter.com]

  • Re:Umm (Score:0, Informative)

    by Anonymous Coward on Thursday March 08, 2012 @04:14PM (#39292693)
    Rubbish.

    In the bugzilla thread, you immediately went apeshit when the reporter didn't like any of your suggestions. You even suggested that he could fork VTE!!! What a pompous, arrogant, load of crap.

    Instead of spraying all over slashdot trying to cover your ass, shouldn't you be spending the time closing the security hole you opened in your code?

    You have got one thing right though. People *should* read the bugzilla thread -- it really shows what charming people there are working on Gnome.

  • Re:Umm (Score:0, Informative)

    by Anonymous Coward on Friday March 09, 2012 @11:08AM (#39300781)

    Very cute how you modded yourself up there, Behdad. And exactly how are we supposed to read the bugzilla report "very carefully" when you've had one of your GNOME dev friends close it from public viewing?

    https://bugzilla.gnome.org/show_bug.cgi?id=664611 [gnome.org]

    That's right folks, a GNOME dev's answer to a glaring security flaw is to try and shut people up from talking about it, and particularly from criticizing his poor response. Now Behdad can tell people whatever story he likes because his actual words are no longer available to be viewed by the public, who are the ones being affected both by his arrogance and his negligence.

    Go ahead, mod me down with the many accounts that you've created in the past few hours to boost your own karma. You know, rather than actually fixing the damn bug. Incidentally, guess who _did_ fix the damn bug? Kees Cook, a developer for Ubuntu provided a patch in the thread that is now _also_ no longer available to the public, thanks to Behdad. That's right, a fix is available, made by an Ubuntu developer (worth mentioning that Behdad himself used to be a Redhat employee), but because Behdad has made a public embarrassment of himself now we don't even get access to _that_, let alone see the truth of the sort of person he really is. The absolute height of irresponsibility, Behdad. You're an embarrassment to the entirety of the GNOME project, and if you think this is going away just because you managed to coax one of your friends into censoring the bug report you're a sadly mistaken, pathetic little man.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...