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

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
>

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

On 2020/08/05 16:17, raf wrote:
> 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 matters for the user too. They need to know whether to use an sftp
or an scp client, and if it's sftp then some things they may want to do
(copying a file *to* a remote server) need a complicated method if using
openssh's sftp client (echo "put foo" | sftp -f - hostname).

On Tue, Aug 04, 2020 at 10:23:57PM -0700, Ethan Rahn <ethan.rahn at
gmail.com> wrote:
> 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
I think the key message worth documenting is the fact
that scp is as powerful as ssh and that to think that
it can only transfer files is a mistake that can lead
to security issues. If users need to be limited to
transferring files only, then their access should be
restricted by the server to sftp only.

Just a thought.

cheers,
raf

On 8/5/20 1:23 AM, Ethan Rahn wrote:
> 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.

Sorry to come into this late but there is a very large camp that simply 
doesn't care. They use scp because they have to in order to transfer 
files due to requirements placed on them by admins. They aren't 
concerned about security nearly as much as they just want to get their 
files from A to B so they can do their work. For these people scp is the 
default because that's what all the instructions and examples are based 
on. It's a big part of the reason why I developed hpn-ssh. We couldn't 
get the users to change their behaviour and they kept complaining about 
slow transfers.

In short - for a whole lot of users scp is just a component of their 
workflow. They don't really think about it unless it's causing problems.

So I'm all for getting rid of scp as long as you can get sftp to work in 
exactly the same way. Then you just get replace scp with a symlink to 
sftp. Which is far easier said than done.