After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697571 - paste security issue
paste security issue
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
3.8.x
Other Linux
: Normal major
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-08 16:24 UTC by Elad Alfassa
Modified: 2021-06-10 20:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
LilyTerm paste confirmation dialogue (23.12 KB, image/png)
2017-01-08 09:09 UTC, Ting-Wei Lan
Details

Description Elad Alfassa 2013-04-08 16:24:20 UTC
Testcase here: http://thejh.net/misc/website-terminal-copy-paste

The title explains the issue pretty well. Even a normal, innocent looking command can hide dangerous code.

<elad> did anyone file a bug for VTE/gnome-terminal to fix this problem? http://thejh.net/misc/website-terminal-copy-paste
<chpe> elad: not filed
<chpe> vte supports bracketed paste (by the application running inside the terminal, but not from API); it's not used by g-t when pasting
<elad> yeah
<elad> chpe: I'll go file a bug then
<chpe> elad: does bash even turn on bracketed paste mode?
<elad> I don't know
<elad> how can I check it?

Can this be fixed by a change in gnome-terminal, or should a bug be filed in each and every of the available shells?
Comment 1 Elad Alfassa 2013-04-08 16:25:45 UTC
<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
Comment 2 Christian Persch 2013-04-08 16:59:57 UTC
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.
Comment 3 Elad Alfassa 2013-04-08 17:46:15 UTC
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?
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-04-10 03:25:22 UTC
The alternate solution is to modify web browsers to only let you copy visible content.
Comment 5 Christian Persch 2013-04-10 16:02:43 UTC
That should happen indeed and independently of any mitigation we might implement in gnome-terminal.
Comment 6 timothyhobbs 2013-04-28 17:57:35 UTC
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?
Comment 7 timothyhobbs 2013-04-28 17:58:49 UTC
The dialogue would of course show the contents of the paste, so the user could then verify if it's safe.
Comment 8 Egmont Koblinger 2014-06-29 01:22:53 UTC
(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.
Comment 9 Egmont Koblinger 2014-06-29 01:33:59 UTC
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.
Comment 10 Egmont Koblinger 2014-06-29 14:09:43 UTC
(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...
Comment 11 Egmont Koblinger 2014-06-29 14:19:08 UTC
Just FYI: https://www.midnight-commander.org/ticket/3229 is another one of  those examples where harmful code can easily be copy-pasted accidentally.
Comment 12 Egmont Koblinger 2014-08-23 11:59:34 UTC
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.
Comment 13 Egmont Koblinger 2014-11-16 10:31:29 UTC
Seems bash-4.4/readline-6.4 will have bracketed paste support:

https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00211.html
Comment 14 Egmont Koblinger 2015-05-07 21:14:43 UTC
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.
Comment 15 Egmont Koblinger 2015-08-03 21:00:48 UTC
See also bug 753197.
Comment 16 Egmont Koblinger 2016-09-16 22:48:54 UTC
FYI: bash-4.4/readline-6.4 are released now. Place this in ~/.inputrc to enable malicious paste protection:

set enable-bracketed-paste on
Comment 17 Egmont Koblinger 2016-09-16 22:54:51 UTC
Sorry, surprisingly the version numbers are bash-4.4 and readline-7.0.
Comment 18 Igor 2016-12-26 12:04:26 UTC
(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?
Comment 19 Egmont Koblinger 2016-12-27 21:07:19 UTC
I've hopefully answered these in https://bugzilla.xfce.org/show_bug.cgi?id=13252.
Comment 20 Ting-Wei Lan 2017-01-08 08:13:50 UTC
(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.
Comment 21 Ting-Wei Lan 2017-01-08 09:09:22 UTC
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.
Comment 22 Igor 2017-01-08 14:57:05 UTC
(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.
Comment 23 1d28ed33 2019-02-10 21:35:08 UTC
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…
Comment 24 Egmont Koblinger 2019-02-10 21:57:05 UTC
> 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?
Comment 25 1d28ed33 2019-02-11 18:04:17 UTC
> 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?
Comment 26 Christian Persch 2019-02-11 19:31:00 UTC
(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.
Comment 27 Egmont Koblinger 2019-02-11 23:06:31 UTC
(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.)
Comment 28 Egmont Koblinger 2019-02-11 23:28:31 UTC
(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.
Comment 29 1d28ed33 2019-02-14 21:22:31 UTC
BTW dropped bash a mail about that bracketed paste mode.

So I guess this issue can be seen as closed…
Comment 30 GNOME Infrastructure Team 2021-06-10 20:29:05 UTC
-- 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.