Mailing List Archive

SSH client and bracketed paste mode
Hello list,

Using a terminal with bracketed paste mode (see [0], [1]), I
am not able to paste text while being in the "~C" command line
mode.

The reason for that is, that while being in that special mode,
openssh-client attempts to interpret the special bracketed paste
start escape sequence, which does not work:

root@localhost:~#
ssh> ^[[200~-L /home/..........long-path-to-socket:/run/....long-path-to-remote-socket
^[.[.201~Invalid command.
~
-bash: /root: Is a directory
root@localhost:~#

I tried to figure out, which of the three involved components
might be at fault. The component stack is:

* terminal
* local shell
* ssh
* remote shell

Just executing xxd on stdin instead with the stack

* terminal
* local shell
* xxd

the data copied and hexdumped did NOT contain the escape sequences,
only clipboard data was hexdumped. Hence I assume that for the
ssh-stack, the problem has to be somewhere between bash and ssh
interaction. This seems to be due to bash disabling and reenabling
bracketed-copy-paste while xxd running:

# bash disabling bracketed-copy-paste
64470 write(2, "\33[?2004l\r", 9 <unfinished ...>
...
64471 execve("/usr/bin/xxd", ["xxd"], [."SHELL=/bin/bash", ...
...
64471 +++ exited with 0 +++
...
# reenabling it after child exit
64470 write(2, "\33[.?2004h", 8 <unfinished ...>


Instead on the ssh stack, local shell also disables bracketed-copy-paste,
but ssh or remote shell activates it again later on:

# Local shell disables it
72353 write(2, "\33[?2004l\r", 9) = 9
...
# ssh is executed
72376 execve("/usr/bin/ssh", ["ssh", "...
...
# ssh login is completed
72376 write(5, "\r\nLast login: Fri Oct 30 17:51:32 2020 from 1.2.3.4\r\r\n", 58) = 58
...
# Ssh or remote shell activates bracketed-copy-paste, control
# sequence is written by ssh to local terminal-fd.
72376 write(5, "\33[?2004hroot@localhost:~# ", 38) = 38
...
# Later on ~C is called while bracketed-copy-paste is active
72376 write(5, "\r\n\33[?2004l\r\33[?2004hroot@localhost:~# ", 49) = 49
72376 select(7, [3 4], [], NULL, NULL) = 1 (in [4])
72376 read(4, "~", 16384) = 1
72376 select(7, [3 4], [], NULL, NULL) = 1 (in [4])
72376 read(4, "C", 16384) = 1
...
# Now copy and paste of ~C command content ("-L ...." string),
# that starts with the bracketed-copy-paste start sequence.
72376 write(7, "\r\nssh> ", 7) = 7
72376 read(7, "\33", 1) = 1
72376 read(7, "[.", 1) = 1
72376 read(7, "2", 1) = 1
72376 read(7, "0", 1) = 1
72376 read(7, "0", 1) = 1


Is this the intended behaviour?


If I understand it right, should ssh-client maybe track the remote
side activating and deactivating bracketed-copy-paste and then
a) when handling "~C" copy and paste doing it according to
bracketed-copy-paste or b) do not allow/perform special handling
of pasted data while in "~C", e.g. by deactivating bracketed-copy-paste
while in "~C" and reactivating it later on? Or should it c) be
completely agnostic to bracketed-copy-paste mode and make users
apply the non-intuitive "workaround" to again be able to copy-paste
the annoyingly long command path from my cheat sheet to an active
SSH connection?

root@localhost:~# cat > /dev/null

~C
ssh> -L /home/..........long-path-to-socket:/run/....long-path-to-remote-socket
Forwarding port.

^C
root@localhost:~#


Depending on the implementation decision, this might have a mild
security impact for the weird border case, where someone copy and
pastes input to a remote terminal, e.g. after reading seemingly
unproblematic commands on a webpage or in a mail. In worst case,
that could allow unwanted remote connections to the local machine
or with "PermitLocalCommand" execute commands on the client.

For the case where the remote machine is compromised, the admin
would need to copy and paste problematic text while seeing it, e.g.
by expanding an attacker-created file using tab expansion and
copy-pasting the file name then (or paste it while writing the
mail via ssh-connection) PLUS make use of the ssh-client induced
(maybe timing-related) transformation of the strings:

# touch $'PwnedReadme.txt\n\n~C\nhelp\n\n\n'
# ls Pw[tab]
... expands it
# stat 'PwnedReadme.txt

~C
help


'

Therefore the admin would be at fault copy-pasting such remote
content without review.

Other data-integrity issues would be pasting rare border cases like:

cat <<EOF > x.txt
hello
~C
help
more
EOF
xxd x.txt

which results in

# xxd x.txt
00000000: 6865 6c6c 6f0a 0a68 656c 700a 6d6f 7265 hello..help.more
00000010: 0a .

Any opinions?

hd

[0] https://www.xfree86.org/current/ctlseqs.html#Bracketed%20Paste%20Mode
[1] https://cirw.in/blog/bracketed-paste

PS: I hope I did not mess up the text because I stumbled multiple
times over inadvertedly activating command mode when copy-pasting
the examples to this mail, written via ssh :-)

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SSH client and bracketed paste mode [ In reply to ]
halfdog wrote:
> I tried to figure out, which of the three involved components
> might be at fault. The component stack is:
>
> * terminal
> * local shell
> * ssh
> * remote shell

Note that the recent bash 5.1rc1 is testing with bracketed-paste-mode
enabled by default for the first time. If you have upgraded recently
then that is the most likely change which has triggered this new
behavior. (It's the new reverse video paste and region which cause
problems for me.)

You might try putting

set enable-bracketed-paste off

into your libreadline configuration ~/.inputrc file to see if that
changes what happens for you. That would isolate the change to bash
5.1rc1 enabling this mode by default in that test release.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SSH client and bracketed paste mode [ In reply to ]
Hi,

lemme correct that for you:

> Using a terminal with bracketed paste mode (see [0], [1]), I
> am not able to paste text while being in the "~C" command line
> mode.
>
> The reason for that is, that while being in that special mode,
the terminal sends the bracketed paste control characters to
OpenSSH, which does not expect it.

> I tried to figure out, which of the three involved components
> might be at fault. The component stack is:
>
> * terminal
> * local shell
> * ssh
> * remote shell

This works as follows:

• terminal sets up normal operation
• local shell starts ssh
• ssh starts remote shell on the terminal
• remote shell instructs the terminal to switch to bracketed paste mode

Now when you use an SSH escape, ssh temporarily accesses the
terminal, but bracketed paste mode is still active, which
leads to confusion.

This is also seen often in terminal multiplexers that themselves
do not implement bracketed paste mode, but one of the programs run
in them enables it. Switching to another program in the multiplexer
makes the other one suddenly get the bracketed paste escape codes.

I fear that the correct solution here is to not use bracketed paste
mode, or to disable it manually while accessing the ssh escape, or
to not paste with the mouse into the escape prompt (pasting using,
for example, GNU screen ^A], will still work).

bye,
//mirabilos (who’d analysed this in the other scenario some time ago)
--
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font. -- Rob Pike in "Notes on Programming in C"
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SSH client and bracketed paste mode [ In reply to ]
On 10/30/20 5:22 PM, Thorsten Glaser wrote:
> Hi,
>
> lemme correct that for you:
>
>> Using a terminal with bracketed paste mode (see [0], [1]), I
>> am not able to paste text while being in the "~C" command line
>> mode.
>>
>> The reason for that is, that while being in that special mode,
> the terminal sends the bracketed paste control characters to
> OpenSSH, which does not expect it.
>
>> I tried to figure out, which of the three involved components
>> might be at fault. The component stack is:
>>
>> * terminal
>> * local shell
>> * ssh
>> * remote shell
>
> This works as follows:
>
> • terminal sets up normal operation
> • local shell starts ssh
> • ssh starts remote shell on the terminal
> • remote shell instructs the terminal to switch to bracketed paste mode
>
> Now when you use an SSH escape, ssh temporarily accesses the
> terminal, but bracketed paste mode is still active, which
> leads to confusion.

It would still be nice if SSH implemented support for it. Bracketed
paste mode is a useful security feature, when combined with terminals
that refuse to paste control characters.

Sincerely,

Demi
Re: SSH client and bracketed paste mode [ In reply to ]
On Sat, 31 Oct 2020, Demi M. Obenour wrote:

> It would still be nice if SSH implemented support for it. Bracketed

I wondered about this for a long while, too.

But I think it cannot be expected of *any* Unix application
to implement bracketed paste mode support especially if it
doesn’t even really do anything terminal-specific itself.

That would be like requiring cat to strip out these control
sequences.

So it’s probably better to not even start.

bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec) ??? Please let MySQL and MariaDB finally die!
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SSH client and bracketed paste mode [ In reply to ]
Thorsten Glaser writes:
> On Sat, 31 Oct 2020, Demi M. Obenour wrote:
>
>> It would still be nice if SSH implemented support for it.
>> Bracketed
>
> I wondered about this for a long while, too.
>
> But I think it cannot be expected of *any* Unix application
> to implement bracketed paste mode support especially if it
> doesn’t even really do anything terminal-specific itself.
>
> That would be like requiring cat to strip out these control
> sequences.
>
> So it’s probably better to not even start.
> ...

Complete following might be too much. But just for the limited
"~C" control mode that might make sense for hardening purposes.

Otherwise the line to copy-paste vulnerabilities might be small,
e.g. "~C" can cause quite unexpected side effects, e.g. with

StreamLocalBindUnlink

Specifies whether to remove an existing Unix-domain socket file
for local or remote port forwarding before creating a new one.
If the socket file already exists and StreamLocalBindUnlink is
not enabled, ssh will be unable to forward the port to the Unix-
domain socket file. This option is only used for port forwarding
to a Unix-domain socket file.

Unlike the documentation, "StreamLocalBindUnlink" will also unlink
any file, not only sockets. Therefore "accidentially" copy-pasting
a local forward command would delete any file on the local machine.

Local commands:

~$ ls -al /home/test/x.txt
ls: cannot access '/home/test/x.txt': No such file or directory
~$ touch /home/test/x.txt
~$ ls -al /home/test/x.txt
-rw-r--r-- 1 test users 0 Oct 31 17:49 /home/test/x.txt

In SSH connection:

~C
ssh> -L /home/test/x.txt:/dev/null

Afterwards on local side:

~$ ls -al /home/test/x.txt
srw------- 1 test users 0 Oct 31 17:49 /home/test/x.txt



I think deleting local files while seemingly working on a remote
machine might be too unexpected for some admins. To secure "~C"
while still being able to copy-paste maybe think of something
like this?

If "~C\n" is typed < 100ms or is inside a bracketed-copy-paste,
then stop remote output and ask user "Want to process input
[input-sanitized] containing at least one control sequence?
If so, type [n-place-alphanum] and return to do so."

If user confirms, put data to input buffer, otherwise discard
it?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SSH client and bracketed paste mode [ In reply to ]
Bob Proulx writes:
> halfdog wrote:
> > I tried to figure out, which of the three involved components
> > might be at fault. The component stack is:
> >
> > * terminal
> > * local shell
> > * ssh
> > * remote shell
>
> Note that the recent bash 5.1rc1 is testing with bracketed-paste-mode
> enabled by default for the first time. If you have upgraded recently
> then that is the most likely change which has triggered this new
> behavior. (It's the new reverse video paste and region which cause
> problems for me.)
>
> You might try putting
>
> set enable-bracketed-paste off
>
> into your libreadline configuration ~/.inputrc file to see if that
> changes what happens for you. That would isolate the change to bash
> 5.1rc1 enabling this mode by default in that test release.

Sorry, this one got lost somehow...

I tested it, the inputrc change exacltly reverts Bash behavior
to the one before the update.


Due to the SSH client being able to delete arbitrary files on
the local machine, forwarding arbitrary ports, which might also
be possibly to trigger when accidentially copy&pasting malicious
content containing (hidden) SSH "~C" commands (only the timing
of the input seems relevant, not tested how far that can be influenced
when e.g. copying from a browser window - at least a standard
terminal to terminal copy&paste is not sufficient), while not
having investigated that I think i will stick to the "cat > /dev/null"
solution to temporarily disable bracketed copy&paste (and therefore
enable SSH command copying) just when I really want to copy and
paste SSH "~C" command(s) from a cheat sheet.

hd

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev