This is not really news as this is an age-old attack with low impact:
rxvt-unicode does not filter end sequences when using bracketed paste mode. You
can try this by following this web page:

https://thejh.net/misc/website-terminal-copy-paste

and using the oh-my-zsh "safe-paste" plugin. Pasted data can escape the
bracketed mode, which might result in unsafe input.

This is confirmed by fetching urxvt source and seeing the definition of
rxvt_term::tt_paste in screen.C.

Patch attached.

As an additional fyi, firefox upstream bug
https://bugzilla.mozilla.org/show_bug.cgi?id=637895(*) is reasonably close
(as it is about the same problem).

(*) Thanks to Mikael (of zsh fame) for pointing this out.

Hi!

This bugreport is unsound for a variety of reasons.

First of all, the safety is not the same as security, and the bracketed
paste mode is not a means for security (for a variety of subreasons, the
main being that pasting a _shell_ command that contains data that the user
doesn't know is insecure with or without bracketed paste mode filtering
out certain sequences).

Secondly, it's not rxvt-unicode's job to implement the security barrier
between e.g. the interwebs and your selection - if an app such as firefox
allows one to select text and then internally selects something else (as
firefox indeed does), then this is a security issue in the application
that can be tricked into putting text into the selection that the user
didn't select.

Third, even if bracketed paste mode would single out this sequence, it's
not a security feature, as the user has no feedback on whether this mode
is enabled, so cannot base her decision to paste on this mode. Advertising
bracketed paste mode as a security feature would trick users into unsafe
behaviour.

Lastly, guessing what is "safe" and what is "unsafe" in the terminal
emulator is the wrong place, as it can't know what the application
interprets. For example, the application might abort paste mode on other
sequences as well (such as ctrl-c). It's also very difficult to implement,
even if there was a list of what is to be filtered out, as the patch
shows, which doesn't manage to filter out sequences at internal borders, so
not giving the false impression that pasting is safe no matter what it
contains.

Therefore, I would suggest reassigning this to firefox or other
applications in Debian GNU/Linux that let you select one text visually,
but then offer a different text as the selection to other apps, as that is
indeed a security problem.

Sorry for the late reply, but as I wasn't included in the reply, I
didn't get any notification. I just stumbled upon it today by chance...

The way I see it, bracketed paste allows the program attached to the tty
to receive clean input from the paste without the terminal interfering.

Ideally, I would like the data to come through *as-is*, 8bit clean.

Unfortunately, bracketed paste is flawed, as it relies on a termination
sequence and doesn't allow escapes. This means that even if I wanted to,
I cannot pass input that includes the termination sequence.

Without filtering the termination sequence at all, there's *no* way to
implement reliably *any* bracketed sequence. It *is* the job of the
terminal program to filter the sequence, and only that sequence, from
the paste. This is not sanitization of the input, it's just protocol.

This patch was produced as a result of some work in zsh, which now uses
bracketed paste to automatically quote (and not execute by default!)
pastes. This is now the default behavior in zsh since 5.1.

Bracketed paste might actually be used by editors, such as vim, to
insert text as-is without having to enter "paste" mode first.

However, bracketed paste needs to be reliable.

We've been discussing the issue of break processing in the zsh ml, and
indeed the patch is still "incomplete" in the sense that Ctrl+C is still
processed by the terminal discipline, and that's definitely something
that should be avoided.

I'd rather try to manually change and restore the terminal mode through
the pty master in order for the bracketed paste to be fully transparent
for all programs, but I didn't get to it yet.

I don't want to go through the route of xterm, which instead filters the
input "pretending" to know what is safe and what isn't, which like you
say, is just guessing.

Firefox has nothing to do with it here, but it shows one of the most
important aspects of a reliable bracketed paste: if bracketed paste is
implemented correctly in the terminal, proper behavior *can* be
implemented at the application level, as zsh now shows.

I understand what you wish for, but I think you are trying to use the
wrong tool here. For starters, can you define what "as-is" means when the
data is binary and the terminal is in utf-8? Or a non-utf-8 filename?

And with filtering it is also not possible to implement this "reliably".

The problem with this is that a large share of pastes would not benefit
from paste mode. It's basically only _some_ multiline pastes that would
benefit from it, while most would either not benefit or suffer negative
effects from it.

zsh doesn't have access to the pty master, and is unlikely to be able to
react fast enough.

The problem isn't that it is guessing, the problem is that is always wrong
- if a program sends different text when asked for a selection then what
the user has selected, this is a bug, which can be security-relevant. No
amount of kludging or guessing or following protocol can fix this in a
terminal emulator, unless the temrinal emulator suffers from the same
problem.

Didn't you just write that zsh doesn't? And why would that be proper
behaviour? The number of times where I paste actual commands into my
shell completely dwarfs the few times where I paste hidden commands from
insecure apps such as firefox - or in other words, the only way to switch
zsh into proper mode would be to disable an option that would put it into
"proper mode".

This is going the same path as firefox - instead of plugging javascript
security holes, we get kludges (such as disabling file urls because
firefox can't guarantee their safety, or randomly renaming your profile
directory instead of keeping javascript from snooping around in your
filesystem).

I very much disagree that keeping the user from pasting text that she or
he wants to paste is proper - it's just more bossing around because actual
bugs (like the one in firefox) don't get fixed.

Encoding sits on top of the construct if we can make the paste
transparent, it won't change the current status quo.

Very true, but I'm absolutely open to discuss on how to fix that.

If we agree that the current scheme is insufficient for any purpose,
let's break it for the better. There's basically no-one using bracketed
paste currently.

To answer with the following:

No, the attached program will never be able to do that reliably. The
terminal needs to do that, if possible, but even that would break down
in the context of a remote pty.

A proper solution might actually to devise on how the pasted content
should be encoded by the bracketed paste in a way that 1) allows
embedded control sequences of any kind 2) they are escaped for the
terminal discipline to pass-though.

In that sense, we could just encode the block in a 7bit-safe encoding
such as base64 or something more efficient.

Not really. Bracketed paste allows to make the distinction between a
human typing and a paste, and that really makes a great difference.

zsh now enables bracketed paste by default. It actually sends \e[?2004l
to all terminals, as the ones we tried that didn't support bracketed
paste simply swallowed the escape.

A bracketed paste is also never executed by default. A newline is
inserted literally (as ^J would), so that any command can be previewed.
The paste is also quoted and the quoting style can be customized with a
prefix argument, so that you can paste into a quote with quotes being
escaped correctly, and invisible characters can always be seen.

It's a major improvement in behavior for pasting in any sense.

I doubt firefox will ever be able to fix this issue in a way that makes
"copying" safe.

Frankly, I do not care, as unicode issues will always be present.
Let's fix bracketed paste.

I'll take this off debians bugtracker now, it really makes no sense to
discuss this there (it's not a discussion forum), the bug should be
reassigned to firefox and/or other programs that suffer from this security
issue, as it can't be fixed in a terminal emulator. Or closed.

If you want to discuss development of urxvt with me, please do so on the
urxvt list (rxvt-unicode@lists.schmorp.de>), or with me privately.

If that were true, nobody would ever have an encoding problem - the problem
is, it isn't true. Grafting encoding on top of a system that doesn't support
it will just result in more mojibake, not correct behaviour. I don't see a
point in supporting something that is broken to begin with.

The problem of bracketed paste is that people are asking for things
that are badly specified, badly implemented, badly thought out and with
ill-defined goals.

That could mean there is little or no demand for it. It's also not clear
what the purpose of it is - everybody, including you, cites security
concerns of some form as reason, i.e., they don't have a real use case.

I can't see how that would be a proper solution (see above).

escaping or using hex would be a lot more conservative, just saying.

Such as? You make a lot of very remarkable claims, but so far have shown
very little to back them - which is something in common with the faction that
wants to "fix" bracketed paste.

So you redact your claim? I am not sure what you mean with this statement,
it doesn't seem to be a reply to the quoted text.

Basing such behaviour on a few terminal (emulators?) you tried is hardly
a good implementation. It's really just a bad hack - what's next,
zsh-certified terminals, and everybody else has lost?

(Hint, this only works on ansi/vt-type terminals).

It would be a major step back for me, so your statement is wrong. Again, it
is ea to make sweeping statements such as these, but more is needed to
convince me, especially when the claims turn out to be wrong.

A good first step that might be all that is needed is to not select text that
the user hasn't selected. That should be near-trivial to implement, and bears
no more difficulty than click-through prevention or similar problems already
taken care of.

In any case, whether firefox will be able to fix this isn't really the
issue - firefox is the *only* place where even an attempt to fix it can be
made.

What kind of unicode problems in terminals/shells etc. do you think of
here? And what is the connection of unicode issues to the existing security
problem (which has nothing to do with unicode)?

Your argument is of the form "let's not fix this security problem, because
other security problems might exist". I think this is a non-starter.

I am not sure it is broken, and quite unconvinced that a solution is easy
to achieve.

The bigger problem (the only thing bracketed paste is being requested for
afaics) is the security issue, and the fix for that can't be implemented
by bracketed paste.