[dev] [st] Hardening bracketed paste mode

[Andrew Mass]

Hello,

I believe bracketed paste mode was originally intended for use cases
like text editors, but it seems like many shells are using it as well
to differentiate typed from pasted text. One advantage of this is
preventing commands from running automatically when pasted into the
terminal. This seems beneficial from a security standpoint. For
example, see: https://thejh.net/misc/website-terminal-copy-paste

st fails with the second example because the bracketed paste end
sequence (\033[201~) is contained within the clipboard buffer (you can
see this in the HTML source), which incorrectly signals to the shell
an early end to bracketed paste mode, allowing the rest of the command
to run as if typed.

One seemingly simple way to prevent this would be to sanitize /
disallow pasting buffers that contain this exact sequence. If
bracketed paste mode is active, it seems incorrect to me to allow
writing an "early" end sequence.

I believe some other terminals take it a step further by sanitizing
all sorts of other potentially "dangerous" characters (e.g.:
https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)

Curious to hear what others' thoughts are on this, and whether a patch
along these lines would be seen as valuable. If so, I could try to
send one over.

Thanks!

[Steffen Nurpmeso]

Andrew Mass wrote in
<CAEJgb2AT6noZjGGR6bDM1ZUa...@mail.gmail.com>:

Thomas Dickey as "the one" wrote about all that:

https://invisible-island.net/xterm/xterm-paste64.html

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)

[fom...@0w.se]

Hello Andrew,

You wrote:
> Curious to hear what others' thoughts are on this

Not a comment about a suggested improvement, but about the feature itself.

On Sat, May 10, 2025 at 03:49:20PM +0100, Andrew Mass wrote:
> One advantage of this is
> preventing commands from running automatically when pasted into the
> terminal. This seems beneficial from a security standpoint

Pasting into a shell is always a sensitive operation and needs caution.
Even though extra safety nets are useful, this one comes with a high
cost even besides the needed additional key presses.

FWIIW I consider using this feature in a typical *nix application,
at least when used as a default, a bad design, because it is stateful
and assumes that the application has full control over and is the only
one going to interact with the terminal.

These assumptions do not generally hold. In certain quite reasonable
workflows and scenarios (e.g. when you lose a remote connection) the
"bracketed paste" becomes a quite annoying nuisance. At least some
of my colleagues feel so as well.

That's why I switch off the "bracketed paste" at least in readline, which
helps with bash and probably with some other shells too, on the computers
I manage. There was not a single request from any user to enable it,
the number of users is in the range of 3-4-digits.

my 2c,
fomha4

[Andrew Mass]

On Sat, May 10, 2025 at 10:22 PM Steffen Nurpmeso <ste...@sdaoden.eu> wrote:
> Thomas Dickey as "the one" wrote about all that:
>
> https://invisible-island.net/xterm/xterm-paste64.html

Thanks for sending this, there was a lot of useful context.

It seems as if xterm's allowPasteControls / disallowedPasteControls
feature was largely intended to be independent from bracketed-paste.
However, one could see how users of bracketed-paste would be
interested in having their terminal prevent controls from being
pasted.

I think this raises a new question: Should st have an (optional?)
feature that prevents control codes from being pasted? This would
behave similarly to xterm's removeControls function. This question is
mostly unrelated to bracketed paste / the original questions in this
thread.

I already have a patch for this, but I am not sure whether I should
submit it for mainline consideration, add it to the wiki, or just
leave it be.

[Vincent Lefevre]

On 2025-05-10 15:49:20 +0100, Andrew Mass wrote:
> One seemingly simple way to prevent this would be to sanitize /
> disallow pasting buffers that contain this exact sequence. If
> bracketed paste mode is active, it seems incorrect to me to allow
> writing an "early" end sequence.
>
> I believe some other terminals take it a step further by sanitizing
> all sorts of other potentially "dangerous" characters (e.g.:
> https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)

It seems that xterm changes ESC to a space and NUL to \0 (2 characters).
The other control characters seem unfiltered, which is fine with zsh.
Note that this is independent on whether bracketed paste mode is active
(for instance, this also occurs in cooked mode).

Even though such characters should be safe if recognized as being
part of the pasted text (it is up to the application running in
the terminal to decide what to do with them), at least ESC can be
confusing as it could be incorrectly interpreted as starting an
arbitrary escape sequence. I suspect that NUL has a special meaning
too.

> Curious to hear what others' thoughts are on this, and whether a patch
> along these lines would be seen as valuable. If so, I could try to
> send one over.

If you want to pass all characters, I'm wondering whether splitting
the pasted text into 2 chunks could be a solution, so that the end
sequence does not appear inside a chunk. But as I've said, ESC could
be misinterpreted. IMHO, the bracketed paste protocol should have
provided a way to pass a pasted ESC character via an escape sequence
(and possibly other control characters, in case they would be filtered
by the terminal).

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

[Vincent Lefevre]

On 2025-05-12 11:10:03 +0200, Vincent Lefevre wrote:
> On 2025-05-10 15:49:20 +0100, Andrew Mass wrote:
> > One seemingly simple way to prevent this would be to sanitize /
> > disallow pasting buffers that contain this exact sequence. If
> > bracketed paste mode is active, it seems incorrect to me to allow
> > writing an "early" end sequence.
> >
> > I believe some other terminals take it a step further by sanitizing
> > all sorts of other potentially "dangerous" characters (e.g.:
> > https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)
>
> It seems that xterm changes ESC to a space and NUL to \0 (2 characters).
> The other control characters seem unfiltered, which is fine with zsh.
> Note that this is independent on whether bracketed paste mode is active
> (for instance, this also occurs in cooked mode).

Some other control characters are actually filtered by xterm
(replaced by a space, except NUL, which is replaced by "\0"). This
seems to correspond to disallowedPasteControls, as documented:

BS,DEL,ENQ,EOT,ESC,NUL,STTY

where

STTY special characters which are set with stty(1).

With zsh (in ZLE), ^\ (quit), ^Z (susp) and ^V (lnext) are not filtered,
contrary to the other ones (like ^C (intr)). I suspect that the cause is
that ZLE changes stty settings internally.

Anyway, it is up to the terminal to decide which character should be
filtered, under which condition, and how, and this could be configurable
like in xterm.

IMHO, whether bracketed paste mode is enabled or not, some of them
should really be filtered, like ESC and the special stty characters,
as the special stty characters would have an effect before they can
reach the application.

[Vincent Lefevre]

On 2025-05-11 09:01:04 +0200, fom...@0w.se wrote:
> On Sat, May 10, 2025 at 03:49:20PM +0100, Andrew Mass wrote:
> > One advantage of this is
> > preventing commands from running automatically when pasted into the
> > terminal. This seems beneficial from a security standpoint
>
> Pasting into a shell is always a sensitive operation and needs caution.
> Even though extra safety nets are useful, this one comes with a high
> cost even besides the needed additional key presses.

Note that one may also paste random data by mistake.
So, safety features are useful in any case.

> FWIIW I consider using this feature in a typical *nix application,
> at least when used as a default, a bad design, because it is stateful
> and assumes that the application has full control over and is the only
> one going to interact with the terminal.

which is the case. It is the application that asks for bracketed paste
mode and deals with it. If you have 2 applications interacting with
the terminal at the same time (without coordination), bad things will
happen anyway.

> These assumptions do not generally hold. In certain quite reasonable
> workflows and scenarios (e.g. when you lose a remote connection) the
> "bracketed paste" becomes a quite annoying nuisance. At least some
> of my colleagues feel so as well.

By "when you lose a remote connection", I suppose that you did a ssh
(in general from an interactive shell). In such a case, it is up to
the application that started ssh to restore the terminal state. This
is needed even when bracketed paste is not supported, as the current
(foreground and background) colors, character set, and other things
set up by curses applications may have been changed on the remote
side. In particular, the alternative character set is very annoying
when it isn't reset, because one cannot see what is written and what
one types.

This is also needed without a remote connection. For instance,
a curses application may crash, thus leaving the terminal in a
bad state.

[Steffen Nurpmeso]

Vincent Lefevre wrote in
<20250512091...@qaa.vinc17.org>:

|On 2025-05-10 15:49:20 +0100, Andrew Mass wrote:
|> One seemingly simple way to prevent this would be to sanitize /
|> disallow pasting buffers that contain this exact sequence. If
|> bracketed paste mode is active, it seems incorrect to me to allow
|> writing an "early" end sequence.
|>
|> I believe some other terminals take it a step further by sanitizing
|> all sorts of other potentially "dangerous" characters (e.g.:
|> https://gitlab.gnome.org/GNOME/vte/-/blob/master/src/pastify.cc)
|
|It seems that xterm changes ESC to a space and NUL to \0 (2 characters).
|The other control characters seem unfiltered, which is fine with zsh.
|Note that this is independent on whether bracketed paste mode is active
|(for instance, this also occurs in cooked mode).

I think any "matured" console program then "does something" to
avoid to output controls as-is. If you are in Unicode mode, you
can simply "wc |= 0x2400" to move to the according Unicode visuals
(and 0x2421 for DEL), else you print ?. (With Unicode there are
then also direction marks etc to strip / take care of, whatever.)
So in my opinion, anything is fine except the very end sequence PE
(and NUL).

...

|If you want to pass all characters, I'm wondering whether splitting
|the pasted text into 2 chunks could be a solution, so that the end
|sequence does not appear inside a chunk. But as I've said, ESC could

Likely not, as you cannot read more than maximally strlen(PE) in
order to avoid blocking for more input: so either you read
bytewise or strlen(PE)-YETREAD. A bytewise reader at least.. you
know.

|be misinterpreted. IMHO, the bracketed paste protocol should have
|provided a way to pass a pasted ESC character via an escape sequence
|(and possibly other control characters, in case they would be filtered
|by the terminal).

Yes. (On the other hand the Unicode BOM is only two bytes, and
was supposed to be sufficient said Mark Davies around 2013, though i cannot
find his email no more, and, except for its position, \E[201~ is
far more random. It can likely only be malicious in some piece of
text to be copy+pasted possibly thought Thomas Dickey and the
other involved?)

--End of <20250512091...@qaa.vinc17.org>