Confirm before pasting multi-line text in non-bracketed paste mode

dnkl commented

2021-01-22 14:18:05 +00:00

Owner

There is no content yet.

dnkl added the

enhancement

label 2021-01-22 14:18:05 +00:00

dnkl referenced this issue

2021-01-27 10:07:06 +00:00

1.7.0 #286

dnkl added a new dependency 2021-01-27 10:07:28 +00:00

#286 1.7.0

dnkl added this to the 1.7.0 milestone 2021-01-27 10:07:38 +00:00

sv commented

2021-01-31 06:53:42 +00:00

Is this necessary in terminal emulator? Sounds like the task for a shell; for example, in bash:

set enable-bracketed-paste on

Is this necessary in _terminal emulator_? Sounds like the task for a shell; for example, in bash: ```sh set enable-bracketed-paste on ```

craigbarnes commented

2021-01-31 08:46:27 +00:00

Collaborator

Is this necessary in terminal emulator?

It's not strictly "necessary", but the terminal is in a unique position to help prevent paste hijacking attacks in one central place, rather than hoping for every shell to do the right thing.

for example, in bash:
set enable-bracketed-paste on

Even bash only just started enabling that option by default a few weeks ago, so it'll probably still be a couple of years before the benefits of it become widespread.

> Is this necessary in *terminal emulator*? It's not strictly "necessary", but the terminal is in a unique position to help prevent paste hijacking attacks in one central place, rather than hoping for every shell to do the right thing. > for example, in bash: > >```sh >set enable-bracketed-paste on >``` Even bash only just started enabling that option by default a few weeks ago, so it'll probably still be a couple of years before the benefits of it become widespread.

👀 1

craigbarnes commented

2021-01-31 12:33:01 +00:00

Collaborator

For context, I was referring to the problem described at http://thejh.net/misc/website-terminal-copy-paste, which was previously mentioned in #305.

craigbarnes closed this issue

2021-01-31 12:33:25 +00:00

craigbarnes reopened this issue

2021-01-31 12:33:35 +00:00

sv commented

2021-02-08 11:12:20 +00:00

For context, I was referring to the problem described at http://thejh.net/misc/website-terminal-copy-paste

Alarmingly, the second example sucessfully exploits input in Bash v5.1.4 with enable-bracketed-paste enabled.

/me votes for the feature with both hands!

> For context, I was referring to the problem described at http://thejh.net/misc/website-terminal-copy-paste Alarmingly, the second example sucessfully exploits input in Bash v5.1.4 with `enable-bracketed-paste` enabled. _/me votes for the feature with both hands!_

😆 1

craigbarnes commented

2021-02-08 12:28:59 +00:00

Collaborator

Alarmingly, the second example sucessfully exploits input in Bash v5.1.4 with enable-bracketed-paste enabled.

PR #312 should have improved that case to some degree. Before that PR, the bracketed paste end delimiter in the copied text would cause the commands to be executed immediately upon pasting. With that PR applied, the text is now only pasted in place and you have to press Enter to run it (or ideally Ctrl+C to cancel).

I think this issue is more about improving the situation in shells that don't enable bracketed paste mode, since even just a newline character in the text is enough to cause commands to be immediately executed in that case.

> Alarmingly, the second example sucessfully exploits input in Bash v5.1.4 with `enable-bracketed-paste` enabled. PR #312 should have improved that case to some degree. Before that PR, the bracketed paste end delimiter in the copied text would cause the commands to be executed *immediately* upon pasting. With that PR applied, the text is now only pasted in place and you have to press <kbd>Enter</kbd> to run it (or ideally <kbd>Ctrl</kbd>+<kbd>C</kbd> to cancel). I think this issue is more about improving the situation in shells that don't enable bracketed paste mode, since even just a newline character in the text is enough to cause commands to be immediately executed in that case.

craigbarnes commented

2021-02-08 12:38:20 +00:00

Collaborator

Another idea for improvement here might be an option to completely ignore pastes containing bracketed delimiters, since it's highly likely to be a pastejacking attack and if it's a one-size-fits-all approach for targetting terminals with or without bracketed paste enabled, it'd prevent the attack in both cases.

dnkl commented

2021-02-08 12:49:38 +00:00

Poster

Owner

Another idea for improvement here might be an option to completely ignore pastes containing bracketed delimiters

Sounds like a good idea. Can't think of any situations where it would be wrong.

One thing that makes this issue a bit harder than what it appears at first sight, is the fact that pasted data is streamed to the client.

I.e. foot reads a chunk of text, decodes it, and writes it to the client. This means scanning the entire paste text isn't possible (using the current implementation anyway).

> Another idea for improvement here might be an option to completely ignore pastes containing bracketed delimiters Sounds like a good idea. Can't think of any situations where it would be wrong. One thing that makes this issue a bit harder than what it appears at first sight, is the fact that pasted data is _streamed_ to the client. I.e. foot reads a chunk of text, decodes it, and writes it to the client. This means scanning the **entire** paste text isn't possible (using the current implementation anyway).

sv commented

2021-02-08 23:28:50 +00:00

PR #312 should have improved that case to some degree. Before that PR, the bracketed paste end delimiter in the copied text would cause the commands to be executed immediately upon pasting. With that PR applied, the text is now only pasted in place and you have to press Enter to run it (or ideally Ctrl+C to cancel).

Ok, here is something interesting. In foot v1.6.2, the first example was unsuccessful. In v1.6.3, 2nd one appears to be mitigated:

...but 1st one now goes through:

Is there a regression by any chance?

> PR #312 should have improved that case to some degree. Before that PR, the bracketed paste end delimiter in the copied text would cause the commands to be executed immediately upon pasting. With that PR applied, the text is now only pasted in place and you have to press Enter to run it (or ideally Ctrl+C to cancel). Ok, here is something interesting. In foot v1.6.2, the first example was unsuccessful. In v1.6.3, 2nd one appears to be mitigated: ![image](/attachments/f9d8b267-bc08-40ca-8d04-cdee51156e67) ...but 1st one now goes through: ![image](/attachments/29357663-57a7-4821-ace2-23e4d3682d5d) Is there a regression by any chance?

image.png

25 KiB

image.png

20 KiB

dnkl commented

2021-02-09 06:27:19 +00:00

Poster

Owner

@sv hmm, weird. Both work for me, in zsh-5.8 and bash-5.1.4, with foot-1.6.3-383-g79e054f.

Granted, that isn't 1.6.3, but I'm not aware of any changes since then that would affect pasting in any way.

@sv hmm, weird. Both work for me, in zsh-5.8 and bash-5.1.4, with foot-1.6.3-383-g79e054f. Granted, that isn't 1.6.3, but I'm not aware of any changes since then that would affect pasting in any way.

sv commented

2021-02-09 06:53:50 +00:00

Both work for me, in zsh-5.8 and bash-5.1.4, with foot-1.6.3-383-g79e054f.

Both fail or both succeed to read the /etc/passwd & show the "bad idea" message?

> Both work for me, in zsh-5.8 and bash-5.1.4, with foot-1.6.3-383-g79e054f. Both fail or both succeed to read the `/etc/passwd` & show the "bad idea" message?

dnkl commented

2021-02-09 18:29:24 +00:00

Poster

Owner

@sv both "work", as in I can see the attempted "hack", and it fails to read /etc/password. Sorry for the confusion; it was early in the morning, before coffee ;)

@sv both "work", as in I can see the attempted "hack", and it **fails** to read `/etc/password`. Sorry for the confusion; it was early in the morning, before coffee ;)

sv commented

2021-02-09 22:51:09 +00:00

That's... Unexpected. First one clearly doesn't "work" for me on 1.6.2 and second on 1.6.3. Maybe cosmic rays flipping the memory bits or Debian-specific packaging of gnu-readline/bash/foot.

craigbarnes commented

2021-02-10 06:07:38 +00:00

Collaborator

I just tried this again with fresh builds of 1.6.2 and 1.6.3, running bash as the shell. For me, the only combination that runs the commands on paste is the second attack with 1.6.2.

@sv are you sure you're not doing something like connecting a 1.6.3 footclient to a 1.6.2 foot --server? I've made that mistake more times than I care to admit.

I just tried this again with fresh builds of 1.6.2 and 1.6.3, running `bash` as the shell. For me, the only combination that runs the commands on paste is the second attack with 1.6.2. @sv are you sure you're not doing something like connecting a 1.6.3 `footclient` to a 1.6.2 `foot --server`? I've made that mistake more times than I care to admit.

sv commented

2021-02-10 10:51:21 +00:00

For me, the only combination that runs the commands on paste is the second attack with 1.6.2.

At least one data point that works for >1 person. 2nd attack with 1.6.2.

@sv are you sure you're not doing something like connecting a 1.6.3 footclient to a 1.6.2 foot --server? I've made that mistake more times than I care to admit.

I'm reasonably certain this is not the case. 1.6.2 is now gone as Debian package wouldn't keep an old binary after upgrade/restart.

Anyway, I've just built foot from c97e5da and think I might be onto something.

When testing performance-optimised, non-PGO build - both attacks are not successful on the first run, but subsequent paste successfully exploits input even after terminal reset.

Demo video:

> For me, the only combination that runs the commands on paste is the second attack with 1.6.2. At least one data point that works for >1 person. 2nd attack with 1.6.2. > @sv are you sure you're not doing something like connecting a 1.6.3 footclient to a 1.6.2 foot --server? I've made that mistake more times than I care to admit. I'm reasonably certain this is not the case. 1.6.2 is now gone as Debian package wouldn't keep an old binary after upgrade/restart. Anyway, I've just built `foot` from c97e5da and think I might be onto something. When testing performance-optimised, non-PGO build - both attacks are not successful on the _first_ run, but subsequent paste successfully exploits input even after terminal reset. Demo video:

recording.mp4

8.0 MiB

dnkl commented

2021-02-11 19:03:26 +00:00

Poster

Owner

Sorry, but I still cannot reproduce. Neither in bash nor zsh.

👀 1

craigbarnes referenced this issue

2021-03-13 11:39:26 +00:00

1.7.0 #286

dnkl removed a dependency 2021-03-13 20:49:24 +00:00

#286 1.7.0

dnkl removed this from the 1.7.0 milestone 2021-03-13 20:49:37 +00:00

khm commented

2023-01-24 11:00:44 +00:00

Hi,

Another place this feature is nice is when you're running TUI programs other than shells. When primary selection contains a lot of text, a stray middle-click can for instance dump a wall of text into an irc channel or a keyboard-driven application. Some irc clients detect and prevent this, but not all, and basically no mail clients (etc) do. So regardless of the shell paste mode, it would be nice to have a confirmation option for pasting multi-line text.

Hi, Another place this feature is nice is when you're running TUI programs other than shells. When primary selection contains a lot of text, a stray middle-click can for instance dump a wall of text into an irc channel or a keyboard-driven application. Some irc clients detect and prevent this, but not all, and basically no mail clients (etc) do. So regardless of the shell paste mode, it would be nice to have a confirmation option for pasting multi-line text.

👍 1

Confirm before pasting multi-line text in non-bracketed paste mode #308