Terminal scrollback written to local disk, including remote ssh sessions.

http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html

by andyfraley • 14 years ago

83 35 14 years ago

bluesign• 14 years ago

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

rmc• 14 years ago

Most sensitive web browser data would not be cached.

gaius• 14 years ago

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

deltaray• 14 years ago

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.

james_andres2• 14 years ago

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

psquid• 14 years ago

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.

james_andres2• 14 years ago

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

wladimir3• 14 years ago

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.

randomdrake• 14 years ago

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.

rlpb2• 14 years ago

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"

dfc2• 14 years ago

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.

accountoftheday• 14 years ago

Full disk encryption provides some level of protection against backdooring.

rlpb2• 14 years ago

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.

ori_b2• 14 years ago

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

zokier• 14 years ago

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

ori_b2• 14 years ago

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.

comice• 14 years ago

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

wladimir3• 14 years ago

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.

simcop2387• 14 years ago

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

spindritf• 14 years ago

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

JoachimSchipper• 14 years ago

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.

joeyh• 14 years ago

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.

nodata2• 14 years ago

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

behdad2• 14 years ago

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

nodata2• 14 years ago

Link?

munchor• 14 years ago

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!

runeks• 14 years ago

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.

archivator• 14 years ago

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

azm• 14 years ago

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.

elwin• 14 years ago

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.

aaron42net• 14 years ago

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.

behdad2• 14 years ago

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

mapgrep• 14 years ago

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

Terminal scrollback written to local disk, including remote ssh sessions.

Related Stories