GNOME Bugzilla – Bug 753197
Filter out control chars when pasting
Last modified: 2018-04-01 19:34:19 UTC
You can paste control chars such as U+03 (^C interrupt), U+04 (^D EOF) and so on. So pasting data from an untrusted source to e.g. a "cat" command is potentially harmful, it may terminate "cat" and execute arbitrary stuff. Or lock up your terminal (U+13 ^S scroll lock) and you have no clue why. Or start visual effects such as coloring the text... xterm swallows these chars while pasting. I guess we should too. (Note: slightly related, obviously more problematic due to usability regression is the newline char: bug 697571).
U+80..U+9F should be dropped as well for the same reason (and xterm drops them too).
Yes.
xterm swallows control chars except \r, \n, \t, ^H and ^?. Also in 8-bit mode it filters out 0x80-0x9F. In UTF-8 mode it lets U+0080-U+009F pass through because it doesn't recognize them as C1. We do handle them as C1, so we need to filter them out too in every charset.
Created attachment 312618 [details] [review] Fix
chpe, what do you think, shall this patch be backported? Just as much as it's security (=> yes), it changes the behavior (=> no).
At least backport to 0-42 is fine, IMHO.
I either backport all the way to 0-36, or not at all :D
Missed the tarball creation, and it's only been tested on my machine so far, so committed to master only.
Can we have an option in vte and gnome-terminal for users to manually enable control character pasting? I know xterm disables it by default, but you can enable it by running it with "xterm -xrm 'XTerm*vt100.AllowPasteControls: true". I agree that it should be disabled by default to prevent it from being used in malicious ways, but pasting control characters does have some valid usecases. 1. Pasting a plain text file that is colored with control characters. Control characters are still widely used in telnet-based BBS to have basic formatting for articles. Some people even use control characters to create images and animations with text. 2. Automate key pressing. Not all programs run in a terminal have a scripting interface, and you will need another program to generate key-pressing events if you want to do the same tasks hundreds of times. If we allow pasting control characters, it can be much easier. Write all keys you want to press in a text editor. Copy and paste them to the terminal, wait for a few seconds, and your work is done.
Continuing in bug 794653.
@Ting-Wei, Answering here, as this bug is somewhat more relevant to your problem than 794653. I'm not explicly against having such an option, but I'm not for it either, and I have no intent to work on this. XTerm has way more options than we do, and I don't think it's the right approach (nor practically maintainable in the long run) to have one for every tiny bit of preference. This particular one sounds like a truly obscure one to me, probably relevant to extremely few people. There are other possible workarounds (e.g. xdotool on X11 that can also insert pauses), and – even though conceptually I hate to say this – as long as you're the only one requesting this feature, maybe the best is if you stick to an older VTE, or patch this feature, or use xterm instead. (Let's also note that a VTE-based app could also work around this limitation by feeding the corresponding bytes, so technically, your desired change could also go to any VTE-based app, not necessarily to VTE. Chances are that simple utilities similar to script, or maybe screen or tmux could also easily inject predefined sequences on a certain event.) Unfortunately we cannot please everyone (it's unreasonable to even try), and I'm sorry but personally I feel like this one could remain unresolved. (But I'm not the project's main guy to have the final word.)
Just for the record: Another important aspect of this fix (not mentioned here earlier) was that prior to this fix it was possible to break out of bracketed paste mode (if the pasted data contained its terminating sequence), so pasting wasn't even safe into bracketed paste aware apps. (See e.g. https://bugs.kde.org/show_bug.cgi?id=392554.)