Deprecation of scp protocol and improving sftp client

[raf]

On Tue, Aug 04, 2020 at 10:23:57PM -0700, Ethan Rahn <ethan.rahn at gmail.com> wrote:

> 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
> >
> 
> It seems that there are a few camps here:

I'm not sure that they are all necessarily different camps.

> * 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.

Command whitelisting and/or restricted shells can allow
authorised uses of backtick shenanigans while
disallowing unauthorised uses of backtick shenanigans.
I think these are the same camp. Some users are allowed
to run arbitrary code. Other aren't. They can coexist.

> * 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.

I really do think that the novice/default user is
someone who also has interactive ssh access and so
there's no problem. Whatever they can execute via scp
with backtick shenanigans, they could more easily
execute with ssh itself.

The problem is when, for example, you only have
scp/sftp access to a remote server, such as your bank,
and you use WinSCP to transfer transaction files to
them to be actioned (people do this where I work), and
the bank hasn't properly protected themselves from this
"vulnerability". I really hope all banks do take this
vulnerability into account (e.g. by just supporting
sftp). It matters a lot for them. But it's an issue for
the bank / remote server, not an issue for the user who
doesn't and shouldn't need to know anything about this
(in the banking case).

It's not novice users that need to think about this.
Most novice/default users have general ssh access and
they are just using it to use scp.

> 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 don't think they will, because, if they want to
disallow general purpose ssh access (i.e. shell
access), then they must discover and implement forced
commands. I think that's the standard way to prevent
general shell access via ssh (at least that's what my
government's cyberspooks recommend). Once they are
administering an ssh server and implementing forced
commands, they are no longer a novice user, surely?

But yes, more documentation is always a good idea
in my opinion. The question is where it should go.

You also have to remember that novice users are not
going to try to compromise their remote server using
this technique. They're novice users, not malefactors.
They are not going to try this, and even if they do,
they are only doing things that are are allowed to do.

> 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.

That sounds sensible. I think something should be done
to make the world realise that this CVE isn't important
in most cases. But its writeup seems OK in that
respect. I think it's a shame that there's a CVE out
there that makes scp look bad, when it's really fine in
most cases, and in cases where it's not fine, there are
solutions to mitigate it. Perhaps the scp manpage
could reference the CVE and list a few tools that can
mitigate the problem, or just reference the CVE and
mention forced commands.

But such documentation might not even belong in the scp
manpage itself. Perhaps it belongs whereever people
searching for CVEs will come across it.

Although I agree that it would be cute to put the
"mkdir -p" example in the scp manpage, and reference
the CVE, and refer the reader to the forced command
information in the sshd_config manpage.

I'd be happy to supply an scp manpage patch if there's
any interest in using it. Just let me know what I
should include. But maybe it doesn't belong there.

> Cheers,
> Ethan

cheers,
raf