6 ms·

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

83 points by andyfraley 15y ago

bluesign 15y ago
It sounds like complaining about "cache" in a browser. Storing scrollback in memory can also store it on disk when swapped.
- rmc 15y ago
  Most sensitive web browser data would not be cached.
- gaius 15y ago
  I'd hope that we all know about mlock() by now http://linux.die.net/man/2/mlock http://linux.die.net/man/2/mlock
- deltaray 15y 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_andres 15y ago
⌘K in the Terminal.app will clear the scrollback of the current window.
- psquid 15y 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_andres 15y 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-terminal-in-mac-os-x-lion http://superuser.com/questions/315174/how-to-open-a-clean-te....
wladimir 15y 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 15y 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 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.
rlpb 15y 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"
- dfc 15y 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 15y ago
    Full disk encryption provides some level of protection against backdooring.
    - dfc 15y ago
      Under what threat model? (Backdooring is also beyond the scope of the initial doiscussion)
  - rlpb 15y 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_b 15y ago
If people have permissions that allow them to look at the content of your unlinked files, you're pretty much hosed already.
- zokier 15y ago
  I think the major attack vector for this is lost/stolen laptops and recycled disks.
  - ori_b 15y 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 15y 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).
- wladimir 15y 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 15y 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 15y ago
    Or just encrypt the whole LVM and create partitions on top of that.
    - wladimir 15y ago
      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.
joeyh 15y 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.
nodata 15y ago
So this is why pasting to gnome-terminal takes a year and a day!
- behdad 15y ago
  No, actually it's not. That's a different issue.
  - nodata 15y ago
    Link?
munchor 15y 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 15y 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 15y ago
Another good reason to have /tmp as a tmpfs, I guess.
azm 15y 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 15y 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 15y 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.
- behdad 15y 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 15y 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/mh11852.html 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.)

83 points by andyfraley 15y ago

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

rmc 15y ago
Most sensitive web browser data would not be cached.
gaius 15y ago
I'd hope that we all know about mlock() by now http://linux.die.net/man/2/mlock http://linux.die.net/man/2/mlock
deltaray 15y 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_andres 15y ago

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

psquid 15y 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_andres 15y 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-terminal-in-mac-os-x-lion http://superuser.com/questions/315174/how-to-open-a-clean-te....

wladimir 15y 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 15y 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 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.

rlpb 15y 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"

dfc 15y 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 15y ago
  Full disk encryption provides some level of protection against backdooring.
  - dfc 15y ago
    Under what threat model? (Backdooring is also beyond the scope of the initial doiscussion)
- rlpb 15y 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_b 15y ago

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

zokier 15y ago
I think the major attack vector for this is lost/stolen laptops and recycled disks.
- ori_b 15y 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 15y 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).

wladimir 15y 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 15y 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 15y ago
  Or just encrypt the whole LVM and create partitions on top of that.
  - wladimir 15y ago
    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.

joeyh 15y 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.

nodata 15y ago

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

behdad 15y ago
No, actually it's not. That's a different issue.
- nodata 15y ago
  Link?

munchor 15y 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 15y 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 15y ago

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

azm 15y 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 15y 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 15y 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.

behdad 15y 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 15y 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/mh11852.html 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.)