Re: SSH client and bracketed paste mode

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux