

Terminal scrollback written to local disk, including remote ssh sessions. - andyfraley
http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html

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

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

------
rlpb
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
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
Full disk encryption provides some level of protection against backdooring.

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

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

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

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

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

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

~~~
nodata
Link?

------
munchor
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!

------
mapgrep
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...](http://docs.info.apple.com/article.html?path=Mac/10.7/en/mh11852.html)).
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.)

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

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

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

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

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

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

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

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

------
runeks
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
Another good reason to have /tmp as a tmpfs, I guess.

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

~~~
james_andres
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...](http://superuser.com/questions/315174/how-to-open-a-clean-terminal-in-
mac-os-x-lion).

