openssh unix dev - Aug 2020 - Deprecation of scp protocol and improving sftp client

On Tue, 4 Aug 2020, raf wrote:
> In such cases, this vulnerability can be mitigated by
> the use of an ssh-specific command whitelisting control
> such as:
Probably just as easy: give the user a restricted shell
(/bin/rmksh) as shell and set their PATH etc. suitably,
to not include any other commands.

bye,
//mirabilos
PS: Full disclosure: I?m the mksh developer
-- 
?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!

On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser <t.glaser at
tarent.de> wrote:
> On Tue, 4 Aug 2020, raf wrote:
> 
> > In such cases, this vulnerability can be mitigated by
> > the use of an ssh-specific command whitelisting control
> > such as:
> 
> Probably just as easy: give the user a restricted shell
> (/bin/rmksh) as shell and set their PATH etc. suitably,
> to not include any other commands.
> 
> bye,
> //mirabilos
> PS: Full disclosure: I?m the mksh developer
I've thought of a valid use for this kind of behaviour
that someone might actually be relying on. :-)

  scp sourcefile remoteserver:'`[ -d /a/b/c ] || mkdir -p
/a/b/c`/a/b/c/targetfile'

(i.e. ensure that the destination directory exists before writing the file to
it)

cheers,
raf

It seems that there are a few camps here:

* The scp power users - this camp believes that scp supporting backtick
notation is fine and that running arbitrary commands is a perfectly fine
thing to do.
* The restricted shell users - this camp believes that scp supporting
backtick may not be the best, and there are various restricted shells which
can prevent this. Power users may belong to this camp.
* The novice users - this camp is surprised to find that scp can be used to
run commands. Once they understand that the server runs "scp -t" it
makes a
little more sense.

The problem that I see here is that this is not going to be obvious to
novice users. If you read the man pages ( https://man.openbsd.org/scp.1 ) I
don't see anything that suggests one could use backticks nor run shell
commands. If the solution to this is that the openssh team includes this as
a note in the man pages and posts under their security page that they are
clarifying that behavior I think that would be fine. Where this is going to
cause pain is if there are novice users who want to have a fileserver ( or
an account ) which disallows ssh access, but allows scp to send/receive
files. Those users are likely going to be bit by this.

I understand that the openssh team is not interested in making changes to
scp, but would a clarification on this being intentional behavior be
possible? Then the novice users could account for this in their restricted
shell setups.

Cheers,

Ethan

On Tue, Aug 4, 2020 at 3:41 PM raf <ssh at raf.org> wrote:
> On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser <
> t.glaser at tarent.de> wrote:
>
> > On Tue, 4 Aug 2020, raf wrote:
> >
> > > In such cases, this vulnerability can be mitigated by
> > > the use of an ssh-specific command whitelisting control
> > > such as:
> >
> > Probably just as easy: give the user a restricted shell
> > (/bin/rmksh) as shell and set their PATH etc. suitably,
> > to not include any other commands.
> >
> > bye,
> > //mirabilos
> > PS: Full disclosure: I?m the mksh developer
>
> I've thought of a valid use for this kind of behaviour
> that someone might actually be relying on. :-)
>
>   scp sourcefile remoteserver:'`[ -d /a/b/c ] || mkdir -p
> /a/b/c`/a/b/c/targetfile'
>
> (i.e. ensure that the destination directory exists before writing the file
> to it)
>
> cheers,
> raf
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>