A look at terminal emulators, part 1

Posted Apr 20, 2018 8:28 UTC (Fri) by georg.s (guest, #110733)
In reply to: A look at terminal emulators, part 1 by anarcat
Parent article: A look at terminal emulators, part 1

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