It is common practice to copy commands from websites and since most users have JavaScript enabled they are vulnerable to pastejacking (demonstration under https://security.love/Pastejacking/). Currently the Xfce4-terminal willingly executes clipboard content that contains newlines as soon as you paste it, posing a potential security risk. Xfce4-terminal shouldn't automatically execute pasted content that contains newlines, instead it should show the user the pasted lines, allow the user to edit these lines if they want to and only actually execute them if the user confirms.
See also https://bugzilla.gnome.org/show_bug.cgi?id=697571.
(In reply to Egmont Koblinger from comment #1) > See also https://bugzilla.gnome.org/show_bug.cgi?id=697571. Egmont, thanks for the link! larivact, does setting set enable-bracketed-paste on solve the issue for you?
Thanks Igor adding "set enable-bracketed-paste on" to the ~/.inputrc indeed prevents the auto execution. But shouldn't it be secure by default? Maybe xfce4-terminal can tell Readline that enable-bracketed-paste should be on? btw: Does the bracketed paste end sequence get escaped? P.S. relevant: https://cirw.in/blog/bracketed-paste
Thanks for the link! It's very useful. Could you please test bracketed paste support I've added in https://git.xfce.org/apps/xfce4-terminal/commit/?id=4094b6bfdf30f48518a2e5bc7a84850fd732d61c? You'll need to set MiscBracketedPaste option to TRUE in terminalrc.
Hi Igor, This patch is fundamentally broken. Bracketed paste mode should only be enabled by applications which know how to handle these bracket escape sequences. Otherwise pasting will result in garbage characters. With this new xfce4-terminal mode, in case it's enabled: - If the app running inside does know how to handle bracketed paste and does enable it (e.g. bash-4.4 with the corresponding readline option) then it's a no-op since it's enabled anyways; - If the app running inside does not know how to handle bracketed paste (e.g. bash-4.3) then pastes will be broken (until a bracketed paste aware, e.g. mc is started up and quit, which reverts bracketed paste mode to its default off state). Plus, it's another config option that should not exist at all, bracketed paste is not meant to make users' life more complicated by having to set more config options at more places, it's meant to be silently doing its job under the hood without being exposed to users. And still, should someone (for reasons I probably could not understand) want to enable this mode at startup, they could still easily do it from .bashrc without any support from xfce4-terminal.
Back to the original topic: bash's new mode is partial protection against the security issues. Why is it partial and not full? First, because bracketed paste is not enabled while and external command is being run (unless that command enables it). So e.g. you're good as long as you're pasting from a webpage into the prompt. But e.g. if a "sleep 100" is running and you're pasting there then your data will not be bracketed and won't be distinguishable from manually typed characters. Second, it's not only the shell but plenty other apps that need to get support for bracketed paste. E.g. vim also has, but let's assume it's disabled for you and you're in command mode. Pasting the characters ":q!" followed by Enter followed by "rm -rf blah" Enter will quit vim and paste the rest to the shell. So it's important that any context of any app you're running is careful enough not to allow to leave that context via pasted data. Not sure if vim's bracketed paste mode is careful enough here or not, I'm not a vim guy. Another approach could be that xfce4-terminal itself grabs the paste hotkeys, examines the buffer's contents, and optionally presents a dialog where the user can reject the paste, or modify the buffer before the paste and so on. One possible problem with this approach (the reason why I was reluctant to go this way in gnome-terminal) is that it easily gets super-duper annoying (hell I wouldn't want the terminal interrupting me with a stupid dialog each time I paste into my editor) and if the user can prevent the dialog from appearing then it's no longer secure at all. This situation could be improved by addressing comment-14 of the aforementioned bug.
(In reply to larivact from comment #3) > btw: Does the bracketed paste end sequence get escaped? This is a brilliant question :) As of vte-0.44 control characters are removed from the pasted data, and as such, it's not possible to paste the "end of pasted data" character. It's also no longer possible to paste ^C (which is likely to interrupt the running process) or ^D (which likely means end of input to the running process causing it to quit) etc. See https://bugzilla.gnome.org/show_bug.cgi?id=753197.
Typo: ... it's not possible to paste the "end of pasted data" *sequence*.
Hi Egmont, Thanks a lot for the info! I agree that the patch turns out to be broken, and will revert it. I also agree with you regarding the paste dialog - it would be annoying, and moreover, wouldn't add much of security. So what would you suggest - rely on the .inputrc method? Thanks again.
Alas there's been no conclusion in the gnome-terminal bug for years. I do not have a clear recommendation what to do. It's a bit up to you. bash-4.4 is brand new, we're kinda waiting for distros to start shipping it, and more importantly, to turn on this option by default. Then... then I don't know how to go on. Maybe it'll be good enough for practical uses. We'll see. Yeah I know it sucks big time to say "I don't know" to a security sensitive problem.
Thanks Egmont for your elaborations! But I still have some questions. If I am not mistaken the hierarchy looks like this: terminal emulator └── VTE terminal emulator widget └── shell └── readline └── program 1. Why does bracketed paste mode have to be supported by the terminal? 2. Why doesn't readline have bracketed paste enabled by default? 3. Couldn't bash just not execute the input buffer when a program exits? 4. How can the terminal detect what readline mode is currently used?
0. readline is built into (part of) some of the shells (incl. bash) and some of the apps (e.g. bc). The rest of the pic is okay. 1. It doesn't _have to_ be supported, but if it's not supported then there's no way an app could distinguish typed data from pasted data. This feature lets a) an app switch on a new mode that marks pasted data, and in turn b) the terminal actually mark pasted data as such. 2. No clue, ask its author. I agree that it should be enabled by default. I'd even go further and say that it shouldn't even offer such a config option, just enable it. 3. Yes it could. Actually that's what it does with bracketed paste enabled, right? It could do other things just as throwing away the available characters when a command finishes, which would be quite annoying as it'd prevent typeahead (see e.g. the apt-get command which reads and throws away the characters just before it exits, I hate that I cannot type ahead the next command). 4. Not sure what readline mode you refer to. As for the bracketed paste mode, the terminal is explicitly instructed to enable/disable this mode.
In terminix and iterm2 there is an advanced paste feature that brings up a dialog allowing the user to preview and edit the paste contents prior to pasting them into the terminal. In terminix there is an option to "Always use the advanced paste dialog" to force this dialog for users that are concerned about paste-jacking. Maybe a similar approach could be adopted here?
Gerald, thanks for the suggestion - I've taken a look at your implementation and opened an issue.
What if a selection would be checked for '\n' chars and they would be replaced with say a space before pasting? Are there any other chars that should be checked?
(In reply to Igor from comment #15) > What if a selection would be checked for '\n' chars and they would be > replaced with say a space before pasting? > Are there any other chars that should be checked? Hello, Is it possible to implement such behaviour in the next version ? Thank you.
Hi Ildar, I have this in my plans, just don't have much spare time, unfortunately.
Thank you, Igor, for your reply. I have found a solution for xterm https://unix.stackexchange.com/questions/45925/how-to-configure-the-double-click-behavior-in-an-x-terminal Putting *cutNewline: false in my ~/.Xresources made the deal. Unfortunately, it does not work for xfce4-terminal
Hi Ildar, The solution you found is about what gets _copied_ to the clipboard or selection, and not about how its contents get _pasted_. If you work solely within your choice of terminal emulator, it's fine. As soon as you start copying from elsewhere, e.g. from a browser, it'll no longer protect you.
Hi Egmont, Maybe it should be another ticket. My problem is about -copying from xfce4-terminal and -pasting to xfce4-terminal Trailing newlines break zsh history, they slow down my workflow. I am obligated to delete newline after each selection.
*** Bug 15103 has been marked as a duplicate of this bug. ***
Igor referenced this bugreport in commit 86d588d51da4374e404c4df04332c4fb5ae9a4a2 Initial version of the "Unsafe Paste" dialog https://git.xfce.org/apps/xfce4-terminal/commit?id=86d588d51da4374e404c4df04332c4fb5ae9a4a2
Igor referenced this bugreport in commit c1421750fb48c7d7722225d8e6467ff4c56ce76e Expose the setting to allow the "Unsafe Paste" dialog https://git.xfce.org/apps/xfce4-terminal/commit?id=c1421750fb48c7d7722225d8e6467ff4c56ce76e
Igor referenced this bugreport in commit 193bf4a7248932c7f156ad69f1668fa183e5045b Check (Ctrl+)+Shift+Ins and middle mouse button click for unsafe paste https://git.xfce.org/apps/xfce4-terminal/commit?id=193bf4a7248932c7f156ad69f1668fa183e5045b
Hi all, first time i write in this bug tracker, hope not to be offtopic. i find unsafe paste popup very (very) annoying, i use to do a lot of copy paste of several lines on terminal, especially when I'm already root, so this warning is superfluous. Looking in Preferences (end code) if found no way to disable it. If there is a way to disable it and i didn't found... please tell me, my mistake. Or should be cute an option to disable this (very) annoying popup. Good night or day wherever you are.
Hi Dave, The checkbox is on the General tab of Preferences, the very bottom of the dialog window.
so it is my mistake, late nite work didn't help for alertness, thank you very much Igor for the ready answer
You're welcome!
I read this... very funny http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinwyc/what_you_see_is_not_what_you_copy.txt and re enabled the option