A look at terminal emulators, part 1

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.