A look at terminal emulators, part 1 [LWN.net]

A look at terminal emulators, part 1

Posted Apr 18, 2018 13:18 UTC (Wed) by anarcat (subscriber, #66354)
In reply to: A look at terminal emulators, part 1 by georg.s
Parent article: A look at terminal emulators, part 1

As-is, the 'Paste protection' section is quite misleading. Your are mentioning the bracketed paste mode, but you don't tell the reader which of the tested terminals actually support it. Similarly, you mention the test page, but don't report any test results against your set of terminals.

That may have not been clear, but all the terminals in the list succeed the first test when bracked paste is enabled in libreadline, with applications that support it.

When you close with the urxvt confirm-plugin while omitting other protections implemented in other terminals (i.e. the default filtering of most non-printable characters implemented in xterm/vte since 2013/2015 which should be very effective against such paste attacks) the reader has to assume the worst: unless I'm using urxvt with confirm-plugin my terminal is vulnerable to this. Thus, perhaps you want to add a note regarding the 2013/2015 improvements in xterm and vte based terminals.

There's only so much I can do. There are billion (and a half) odd features, corner cases and oddities in terminal emulators. And yes, some terminals have peculiar behavior with certain escape sequences that change titles or can execute arbitrary code. I forgot about that in my review. But if you scroll up to the other comments, you'll see it is actually worse than what you describe: urxvt is vulnerable even to some normal copy-paste bracketed mode *and* confirm-paste escapes.

Now, this is exactly what comments sections are for! :) Could you clarify exactly which improvements happened in xterm and vte to work around those issues and when?

Btw, is there a reason why your table is missing tilix while it's mentioned in the text?

It's one of the terminals that didn't make the full review list. It's only mentioned as an aside, an alternative to Terminator. In the ever growing list of "not evaluated terminals", it's in the "too similar to other stuff", probably because it's like Terminator.

to post comments

A look at terminal emulators, part 1

Posted Apr 20, 2018 8:28 UTC (Fri) by georg.s (guest, #110733) [Link] (2 responses)

> Could you clarify exactly which improvements happened in xterm and vte to work around those issues and when?

As I wrote in my previous comment, the improvement in xterm and vte I'm referring to is the control character filtering (that is enabled, by default):

Implemented in xterm in 2013:
http://invisible-island.net/xterm/xterm.log.html#xterm_292

Implemented in vte in 2015:
https://bugzilla.gnome.org/show_bug.cgi?id=753197

This should protect against:

- escaping from a running `cat > /dev/null` (into a shell) when pasting something into that terminal (i.e. when using that terminal as a paste preview buffer)
- when pasting something into the insert mode of a console vim (running in a terminal), escaping into command mode or the shell
- injecting an end-of-paste-mode sequence in a paste when relying on the terminals bracketed paste mode

See also this Security SE answer: https://security.stackexchange.com/a/52655/42507

A look at terminal emulators, part 1

Posted Apr 21, 2018 18:44 UTC (Sat) by anarcat (subscriber, #66354) [Link] (1 responses)

I tested xterm 327 on Debian and 330 on Fedora. I have also tested GNOME Terminal 3.22.2 and 2.26.2 (against on Debian/Fedora). None were effective against the attacks if bracketed-paste was not enabled in the shell which is the default configuration in both cases. As documented, if bracketed paste is configured, then there is some protection, but I would argue that the protections shouldn't be application-specific: the terminal shouldn't dump random escape sequences on the terminal like this.

So yes, maybe the article's text could have been more explicit about this, but I think I did my homework and tested the configurations you are referring to: I did not find them satisfactory.

Thanks for the updates, however!

A look at terminal emulators, part 1

Posted May 10, 2018 20:22 UTC (Thu) by georg.s (guest, #110733) [Link]

I really don't understand how you would be able to paste 'random escape sequences' into recent versions of xterm or Gnome-Terminal.

All 3 links I included in my last email clearly state that recent versions of xterm/gnome-terminal by default filter out most control characters, including escape. Basically only carriage return, newline, tab, backspace and del should get through.

Thus, if you paste some web-site content into a running `cat > /dev/null` you should be safe as an attacker can't escape (no pun intended!) from it. Similar story for a terminal editor. Also, an attacker isn't able to inject a end-bracket escape sequence into the pasted content (as the escape control character is filtered).

Thus, if you are really able to paste some supposedly filtered-out control characters you should open a bug report against xterm/gnome-terminal.

But I doubt it. See for example: https://georg.so/pub/cat.html

On Fedora 27, with gnome-terminal-3.26.1-1.fc27.x86_64 pasting this example into a `cat > /dev/null` doesn't terminate it. The control character is filtered out, as expected.

It's also filtered out in an xterm-330-3.fc27.x86_64 with default settings.

It isn't filtered out when I paste it into a `cat > /dev/null` inside a rxvt-unicode-9.22-6.fc27.x86_64 or an `xterm -xrm 'XTerm*vt100.AllowPasteControls: true'`. In those terminals the paste terminates the cat and the hidden command is executed.

Similar example: https://georg.so/pub/bash-vi.html

In this case an escape control character is included in the pasted content. Again, it's properly filtered with gnome-terminal and xterm. The escape from insert-mode in bash (with vi key bindings) only works with the rxvt-unicode and xterm/AllowPasteControls.

Also, I haven't explicitly configured zsh-5.4.1-2.fc27.x86_64 for bracketed paste mode - but pasting multiline input doesn't execute the lines in zsh - in contrast to bash. Apparently, it's enabled by default in recent zsh versions.