This looks to be a serious issue.

The video link that was provided in the explanation does a very good job of illustrating the problem.

http://www.youtube.com/watch?v=LgNLHskYvVE

My heart jumped when he ran strings on the temp file system and the contents of his scrollback from the SSH session were shown.

I guess I had always assumed that stuff wasn't going to be written to any local disk in any way.

This sounds like a serious issue if you're using programs such as apg to generate and print random passwords/passphrases to the terminal. Especially if you use them as encryption keys. The keys might well linger around in plaintext on your disk.

This is why full disk encryption is useful (as opposed to, say, just encrypting /home). Unexpected data leaks will often remain encrypted.

Edit: added "often"

I agree with you but to be precise full disk encryption does not provide any benefit that is not met by encrypting user writeable mounts. Encrypting /usr, /bin, /lib etc does nothing in this situation.

The point is to catch the unexpected, just as this scenario was unexpected.

I can't think of a realistic situation right now that will catch you out, but with full disk encryption I don't have to.

Full disk encryption provides some level of protection against backdooring.

Under what threat model? (Backdooring is also beyond the scope of the initial doiscussion)

If you have an encrypted home directory but not encrypted tmp (though you should!) then you can set the TMP environment variable to ~/tmp (and create a tmp dir in your home dir) and libvte will write to there instead (confirmed with gnome-terminal).

Encrypted /tmp and swap partitions (with random keys, generated at each bootup and stored only in memory) seems like a good precaution in any case.

Rather than bothering with encrypted /tmp I believe lots of people are advocating using tmpfs with /tmp. This way data stays in ram and only possibly goes to swap. In the worst case you have to read the data from the disk again, in the best case it's right there in ram and reads back fast. I've heard a number of programs that make lots of small files in /tmp will benefit from this, but ideally the disk cache would suffice.

This still means that an encrypted swap is a good idea. Either that or don't even have it as a separate partition, since some point in linux 2.6 series of kernels it got to be very efficient at using a file as swap. This means that you've only got one set of keys to manage, and it's much easier to setup (in fact it's likely supported by nearly every distro that supports encrypted root filesystems out of the box).

I personally like to name my swap files /WIN386.SWP

Or just encrypt the whole LVM and create partitions on top of that.

Right, that's also possible, but I like the new key every boot as it gives forward security. Even if the key for the whole image is cracked (which is easier to bruteforce than a completely random key as it is usually human-memorizable), it will not be possible to access the swapfile/temp contents.

Yes, but then it's just a matter of waiting for another program that does something like this and doesn't honour TMP. Better to just encrypt /tmp.

So this is why pasting to gnome-terminal takes a year and a day!

No, actually it's not. That's a different issue.

Link?

As a developer of a Vte terminal for elementary OS, this comes as another reminder that Vte is really bad. Firstly, I was really angry with the fact that it couldn't search for "hello" in the same line. For example, it would only find the first instance of "hello" in a line, and then skip to the next one in a different line.

Now this security issue, it's very dangerous and causes many issues.

Thanks a lot for warning me, I probably will stop using Vte, I've just been recommended TermKit and others, time to check those out!

While it's nice that someone is raising this genuine security issue, for most people the bigger issue is going to be unencrypted swap.

Unencrypted swap means ANY sensitive data in memory may well end up on disk (including a term buffer that has been carefully kept away from /tmp by the emulator author!).

Surprisingly, many Linux distros, including Ubuntu, do NOT encrypt swap by default. That's probably something that should be higher priority than this specific (Linux platform specific) bug, IMHO.

OS X, for what it's worth, DOES use secure swap by default starting with Snow Leopard (http://docs.info.apple.com/article.html?path=Mac/10.7/en/mh1...). In prior releases, turning it on is a single checkbox. (There is at least one Google hit saying it was off by default in 10.6, but that's not the case, it was off in 10.5.)

FWIW, I've also seen this cause the terminal to freeze for seconds at a time when there's heavy write contention to a slow SSD.

If people have permissions that allow them to look at the content of your unlinked files, you're pretty much hosed already.

I think the major attack vector for this is lost/stolen laptops and recycled disks.

I'd be just at least as worried about data sitting in named files (not to mention swap). If you're worried about lost/stolen laptops, encrypt the disk.

It sounds like complaining about "cache" in a browser. Storing scrollback in memory can also store it on disk when swapped.

I'd hope that we all know about mlock() by now http://linux.die.net/man/2/mlock

Yes, it sounds like it. The difference being that most people expect the browser to cache data to disk and it even uses this wording in the preferences. Most people using the command line don't expect the data in the scrollback to be written to disk.

Most sensitive web browser data would not be cached.

If the author really wants this on disk, would application-level encryption of the files it is writing to /tmp be overkill?

The standard trick with encrypted swap on Linux is to pull an encryption key out of /dev/urandom on boot and never store it anywhere. I suspect libVTE could do something similar without a lot of code, though it would be a bit strange for a terminal emulator to depend on crypto libraries.

Yes, that's what I want to do. My main goal redesigning the buffer was to 1) fix memory fragmentation, 2) make unlimited scrollback possible. I offered to find some time on a weekend to add a caching layer, a compression layer, and an encryption layer. But the author of that report was more interested in getting publicity I guess, so ignored my offer and made it look like I said I won't fix this. Well, NOW it's harder to justify taking time off my personal life to work on this...

Is there any particular reason people don't use plain old xterm. I know that it does not provide tabs, but other than that what are the problems that people face when using xterm. I have had utf8 support, zoom and copy paste working on it forever.

I ignored xterm because the defaults were ugly. Then I figured out how to use a nice font at a reasonable size and added tmux, and I haven't looked back.

So if the data is only present in the free space of the disk, sfill (in the secure-delete package in Ubuntu) should remove this data right?

Might be a good idea to set up a once-a-week cronjob that does this in any case.

Another good reason to have /tmp as a tmpfs, I guess.

⌘K in the Terminal.app will clear the scrollback of the current window.

In OS X Lion your scrollback is maintained between subsequent launches of the Terminal, especially noticeable between reboots when "Reopen windows when logging back in" is ticked. I mentioned this because a very similar issue, see: http://superuser.com/questions/315174/how-to-open-a-clean-te....

This is specifically a flaw in the libVTE terminal library, which OS X's Terminal.app is not, to the best of my knowledge, based on.