<chpe> elad: looking at a typescript of running bash, I don't see the escape sequence that turns it on... and in bash source code, no mention of bracketed paste
<chpe> elad: so yes g-t should be fixed to use it for paste, but if it's unhandled in the terminal app, it's not much use :-)
<elad> I'll also file a bug in bash then

Turns out that bracketed paste doesn't actually solve the problem, since the pasted text itself could contain the end-paste sequence.

Now I do think that nevertheless g-t should make use of this, and this needs new vte API since I don't think we can make vte_terminal_feed unconditionally do this because that might break applications.

Can we control the pasted line? if so, can we scan it for end-paste sequences and remove every instance? Is there anything that might break if we do that?

The alternate solution is to modify web browsers to only let you copy visible content.

That should happen indeed and independently of any mitigation we might implement in gnome-terminal.

Could we not do this in a similar way to most IRC clients? That is, pasting anything that is one line, and popping up some kind of confirmation dialogue if it's longer?

The dialogue would of course show the contents of the paste, so the user could then verify if it's safe.

(In reply to comment #3)
> Can we control the pasted line? if so, can we scan it for end-paste sequences
> and remove every instance? Is there anything that might break if we do that?

(In reply to comment #4)
> The alternate solution is to modify web browsers to only let you copy visible
> content.

Combining these, I'm wondering if we can just remove the Escape character (or any non-printable characters) when accepting a paste.  I don't think we'd break anything.  (How would the Escape character normally appear in the copy-paste buffer?  I don't think any normal applications put it there under normal circumstances, you'd need malicious code for that.)

I don't think we have a reasonable chance convincing browser developers.  Moreover, I don't think it should be the browser's job.  How could it know where the text is going to get pasted and what are the unsafe characters there?

With this approach, shells would still need to be patched to enable bracketed paste, but this sounds reasonably doable.


(In reply to comment #6)
> Could we not do this in a similar way to most IRC clients? That is, pasting
> anything that is one line, and popping up some kind of confirmation dialogue if
> it's longer?

I'm afraid this behavior might annoy users way too much.

Note 1: Shells would need to toggle bracketed paste mode back-n-forth when displaying the prompt and when launching a command (so that it's off when a command is executed). This would mean that we're safe if the user pastes to the command line, but it's still dangerous if the user eagerly pastes while a previous command is still running.

Note 2: It's not just the Escape character, U+9B should also be removed if we ever get to address bug 730154.

(In reply to comment #6)
> Could we not do this in a similar way to most IRC clients? That is, pasting
> anything that is one line, and popping up some kind of confirmation dialogue if
> it's longer?

If we decide on this approach, we shouldn't forget that pasting is handled by VTE, rather than gnome-terminal.  And we sure wouldn't want VTE to bring up a confirmation dialog, it really belongs to g-t.  So we'd need to rethink which step is whose responsibility, implement the corresponding API, etc...

Just FYI: https://www.midnight-commander.org/ticket/3229 is another one of  those examples where harmful code can easily be copy-pasted accidentally.

xterm has a feature to quote each char during paste (to be more precise, prefix every byte with a ^V):

bash$ echo -ne '\e[?2005h'
bash$
<pasting three lines of text>
bash$ first line^Msecond line^Mthird line^M<cursor_is_here>

---

Do you guys like this approach?

Bash would still be need to be patched.  Or if it had a preexec hook (or if you're willing to misuse the debug trap for this) then maybe you can emit ^[[?2005h from the prompt and ^[[?2005l from the preexec.

One thing I don't like is that the feature hardcodes that ^V is bound to pasting the next char literally in whichever app wants to have safe pasting.  Should you change that, you're out of luck.  E.g. in midnight commander it's equivalent to page down by default, that will need to be changed and ^V disallowed from being reassigned.

---

It prefixes every _byte_ of pasted text with ^V.  I guess it's a bug, I'll try to get it fixed.

In bash it happens to work because ^V is its escape character for literally inserting next byte, and it also (accidentally?) combines broken UTF-8 (with ^Vs in the middle) back to the proper Unicode character.

zsh swallows the non-ascii characters, the Linux kernel's tty cooked mode (e.g. when running the "cat" command, with the default stty lnext=^V) results in a few replacement symbols.  These are fair enough since the input is indeed invalid UTF-8.  Also, problems may arise if the feature is used over luit or maybe even over screen/tmux.

Seems bash-4.4/readline-6.4 will have bracketed paste support:

https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00211.html

Just occurred to me: _if_ we decide to implement a popup dialog, we can make it conditional to bracketed paste mode being disabled.  Whenever it's enabled, we can probably assume that the application knows what's happening and it's fine to send arbitrary data.

See also bug 753197.

FYI: bash-4.4/readline-6.4 are released now. Place this in ~/.inputrc to enable malicious paste protection:

set enable-bracketed-paste on

Sorry, surprisingly the version numbers are bash-4.4 and readline-7.0.

(In reply to Egmont Koblinger from comment #16)
> FYI: bash-4.4/readline-6.4 are released now. Place this in ~/.inputrc to
> enable malicious paste protection:
> 
> set enable-bracketed-paste on

It seems setting this helps with both hijacks from http://thejh.net/misc/website-terminal-copy-paste, right? Is there anything else to be done in the terminal or vte?

I've hopefully answered these in https://bugzilla.xfce.org/show_bug.cgi?id=13252.

(In reply to Egmont Koblinger from comment #8)
> (In reply to comment #3)
> > Can we control the pasted line? if so, can we scan it for end-paste sequences
> > and remove every instance? Is there anything that might break if we do that?
> 
> (In reply to comment #4)
> > The alternate solution is to modify web browsers to only let you copy visible
> > content.
> 
> Combining these, I'm wondering if we can just remove the Escape character
> (or any non-printable characters) when accepting a paste.  I don't think
> we'd break anything.  (How would the Escape character normally appear in the
> copy-paste buffer?  I don't think any normal applications put it there under
> normal circumstances, you'd need malicious code for that.)
> 

I think pasting escape characters does have valid usecases. Please see https://bugzilla.gnome.org/show_bug.cgi?id=753197#c9.

Created attachment 343110 [details]
LilyTerm paste confirmation dialogue

(In reply to Egmont Koblinger from comment #10)
> (In reply to comment #6)
> > Could we not do this in a similar way to most IRC clients? That is, pasting
> > anything that is one line, and popping up some kind of confirmation dialogue if
> > it's longer?
> 
> If we decide on this approach, we shouldn't forget that pasting is handled
> by VTE, rather than gnome-terminal.  And we sure wouldn't want VTE to bring
> up a confirmation dialog, it really belongs to g-t.  So we'd need to rethink
> which step is whose responsibility, implement the corresponding API, etc...

LilyTerm, which uses GTK+ 2 and an old version of VTE, already has a confirmation dialogue for pasting text including newlines.

(In reply to Ting-Wei Lan from comment #21)
> > If we decide on this approach, we shouldn't forget that pasting is handled
> > by VTE, rather than gnome-terminal.  And we sure wouldn't want VTE to bring
> > up a confirmation dialog, it really belongs to g-t.  So we'd need to rethink
> > which step is whose responsibility, implement the corresponding API, etc...
> 
> LilyTerm, which uses GTK+ 2 and an old version of VTE, already has a
> confirmation dialogue for pasting text including newlines.

I think VTE could implement an option to replace newline chars with a space, for example. Terminal apps would expose this option for their users and could also add some fancy dialogs, like LilyTerm's.

This issue is **NOT** fixed, see: https://gitlab.gnome.org/GNOME/vte/issues/92

As https://thejh.net/misc/website-terminal-copy-paste explains:
> Bracketed Paste Mode DOES NOT always fix this because the end sequence can be inside the text you paste unless your terminal emulator filters out the bracketed paste characters when pasting! 

And I can still reproduce this…

> unless your terminal emulator filters out the bracketed paste characters when pasting

Which VTE does, see comment 15.

> And I can still reproduce this…

I cannot.

Have you enabled bracketed paste mode in bash?

> Have you enabled bracketed paste mode in bash?

No.
And I should not need to, as users should be protected by default. So either change the defaults here, or maybe use another solution.

Also, if the user does not have this enabled for one shell they have installed, could not the "exploit" (aka "copy text") actually just start "bash" even in a – say – zsh shell (if bash does not have this mode enabled, but zsh has), and thus bypass this protection?

(In reply to 1d28ed33 from comment #25)
> > Have you enabled bracketed paste mode in bash?
> 
> No.

Then you can't complaing that it's not working, can you!

> And I should not need to, as users should be protected by default. So either
> change the defaults here, or maybe use another solution.

It'd be up to bash/readline to enable bracketed paste by default; take that up with their maintainer(s).

> Also, if the user does not have this enabled for one shell they have
> installed, could not the "exploit" (aka "copy text") actually just start
> "bash" even in a – say – zsh shell (if bash does not have this mode enabled,
> but zsh has), and thus bypass this protection?

No.

Also it's getting quite tiresome to have people claim that this is an exploit on *vte* whereas the problem actually is that whoever is putting text on the clipboard (i.e., firefox) is putting text there that differs from what the user *thinks* will be put there.

(In reply to 1d28ed33 from comment #25)

> could not the "exploit" (aka "copy text") actually just start
> "bash" even in a – say – zsh shell if [...] zsh has [this mode enabled]

If pasting untrusted data can make your zsh start a bash, then how is your zsh protected against these kinds of attacks, again?

(In reply to Christian Persch from comment #26)

> It'd be up to bash/readline to enable bracketed paste by default; take that
> up with their maintainer(s).

Unfortunately I don't have high hopes here. E.g. bash has just enabled checkwinsize by default in 5.0, something which IMO shouldn't only have been enabled about two decades ago, but the entire option and thus the possibility of _not_ checking the window size (in interactive shells) removed. It just used to be a constant source of troubles, for what, for like gaining a few milliseconds in interactive shells?

In my firm opinion, bracketed paste mode should be enabled by bash without any config option (or if really necessary, an option could disable it). In reality, I expect bash's author to flip the default in a decade or two from now :(

Probably distributions are a better starting point to get this feature widely deployed. (But then, see bug 697475 comment 61.)

That being said, IMO bash's default being "security off" doesn't mean it's VTE to blame, nor that it's necessarily VTE's task to jump in and try to protect it. YMMV.

My real concern is: if VTE presents a popup dialog each time the paste buffer contains newlines then it easily becomes extremely annoying (especially considering use cases like pasting multiline text to a text editor), and users will disable that popup (if we let them; or switch to another terminal emulator if we don't), and they're back to being vulnerable. Security and user-friendliness almost always work against each other. If security comes with true annoyance, users will disable security. That's why in this particular case I believe it's much better to address this problem in bash, rather than in VTE / GNOME Terminal. (I thought I had already explained it, but apparently not here, not sure where.)

(In reply to Christian Persch from comment #26)

> the problem actually is that whoever is putting
> text on the clipboard (i.e., firefox) is putting text there that differs
> from what the user *thinks* will be put there.

Unfortunately, it's absolutely not feasible to address the problem from this direction.

HTML (but we could also say e.g. PDF) has extremely complex capabilities, like fixed and relative positioning (that is, the next letter jumping to a totally different place on the screen, perhaps partially or completely offscreen), text over a background (which might also look as text), overlapping text, extremely small font etc.

Browsers have a pretty hard time to show you where the string you search for is found on the page, and to bring that part of the page onscreen.

Constructing a rendering engine that supports all the features specified by HTML+CSS or PDF is an extremely complex task, but it's something that's pretty clarly definend and needs nothing more than proper engineering, as we know it today. Interpreting the result, knowing how the user perceives it is practically impossible.

Also let's mention that a HTML or PDF page can ship its own font where e.g. an "r" looks like "l", and an "m" looks like "s". You might think you're copy-pasting a command that will list a file, while in fact it'll delete it.

To protect against malicious copy-pasting, HTML and PDF and whatnot formats should have been built up with this security protection in mind from scratch, resulting in way less powerful capabilities. But then whichever party would've first disobeyed this principle would have gained a lot of market advantage by giving more features, nicer look etc. to the average user. Such a principle would've been doomed to fail.

The source of the copy-paste being unreliable is something we just have to accept as inevitable.

BTW dropped bash a mail about that bracketed paste mode.

So I guess this issue can be seen as closed…

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7286.