Mailing List Archive

I conjecture that only few of the existing use cases rely on remote expansion.

In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all.

Regards,
Uri

> On Aug 3, 2020, at 02:50, Jakub Jelen <jjelen@redhat.com> wrote:
>
> ?On Sat, 2020-08-01 at 00:17 +0000, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> Why can the local and remote paths be sanitized?
>
> Because remote path is *expected* to be expanded by remote shell before
> executing remote scp. If you sanitize it in any way, you will break
> existing use cases.
>
>> Regards,
>> Uri
>>
>>>> On Jul 31, 2020, at 19:57, Ethan Rahn <ethan.rahn@gmail.com> wrote:
>>>
>>> ?I wanted to bring this up again due to:
>>> https://github.com/cpandya2909/CVE-2020-15778/. This showcases a
>>> clear
>>> issue with scp which it sounds like cannot be fixed without
>>> breaking scp.
>>> This seems like it would lend some impetus to doing _something_,
>>> even if it
>>> breaks scp or necessitates using something new.
>>>
>>> Cheers,
>>>
>>> Ethan
>>>
>>>> On Wed, Jul 15, 2020 at 7:47 AM Thorsten Glaser <
>>>> t.glaser@tarent.de> wrote:
>>>>
>>>>> On Wed, 15 Jul 2020, Red Cricket wrote:
>>>>>
>>>>> I have had this in my .bashrc for years:
>>>>>
>>>>> alias scp='rsync -avzP'
>>>>
>>>> Similar, though I named it rcp because nobody has the real rcp
>>>> installed
>>>> any more, but sometimes I need scp to connect to systems that
>>>> lack rsync.
>>>>
>>>>
>>>> https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=mksh/rcp;hb=HEAD
>>>>
>>>>> maybe rsync is a better replacement for scp than sftp would be?
>>>>
>>>> It could be, were it not under a restrictive licence…
>>>>
>>>>
>>>> This doesn’t preclude people from making SSH’s builtin transfers
>>>> better, though.
>>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev@mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> --
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
>

Blumenthal, Uri - 0553 - MITLL wrote:
> I conjecture that only few of the existing use cases rely on remote expansion.

For local-to-remote operation your conjecture may be correct,
for remote-to-local not so much.

It's a fairly key feature that scp globs on the remote, without roundtrip,
and the SFTP protocol doesn't offer a method to do so.


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

On Mon, Aug 3, 2020 at 9:51 AM Blumenthal, Uri - 0553 - MITLL
<uri@ll.mit.edu> wrote:
>
> I conjecture that only few of the existing use cases rely on remote expansion.
>
> In any case (no pun intended), IMHO it would be better to break a few of the current use cases but leave the majority functional - than kill scp for all.
>
> Regards,
> Uri

Especially with "WinSCP" users still out there.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:

> I conjecture that only few of the existing use cases rely on remote expansion.

No, this is used all the time.

scp remotehost:foo\* .

(Unless rsync is available, but sadly that’s ? GPLv3 and ? not
universally installed.)

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I hear you - but it seems that the choice is between (a) limiting "scp" functionality to address the security vulnerability, and (b) killing "scp" altogether.

I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .".

Especially, since (almost always) I have equal privileges on both local and remote hosts, so in that case I just originate that "scp" from that remote. ;-)

TNX


?On 8/3/20, 11:09, "Thorsten Glaser" <t.glaser@tarent.de> wrote:

On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:

> I conjecture that only few of the existing use cases rely on remote expansion.

No, this is used all the time.

scp remotehost:foo\* .

(Unless rsync is available, but sadly that’s ? GPLv3 and ? not
universally installed.)

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:

> I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .".

That would be the same as killing scp…

> Especially, since (almost always) I have equal privileges on both
> local and remote hosts, so in that case I just originate that "scp"
> from that remote. ;-)

There’s privilegues, and there’s network (NAT gateways or
firewalls in between)…

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 8/3/20, 13:18, "Thorsten Glaser" <t.glaser@tarent.de> wrote:
On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:

>> I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .".
>
> That would be the same as killing scp…

Definitely not for me - and I'm pretty sure there are others in the same boat/position. So, again - the choice is between "killing scp" for some, and killing it for everybody. And I'd much prefer that we don't enforce "misery spreading" to cover everybody,

>> Especially, since (almost always) I have equal privileges on both
>> local and remote hosts, so in that case I just originate that "scp"
>> from that remote. ;-)
>
> There’s privileges, and there’s network (NAT gateways or
> firewalls in between)…

True. That's a good point. My use case doesn't include/involve crossing firewalls. I think there's enough users on either side of this issue (those who need "scp" mostly/only within the cluster/domain, and those who use "scp" across NAT and/or firewall(s)). I'd say that there are greater security risks for the "firewall-crossing" users, so they should worry about potential vulnerabilities/exploits more.

Thorsten Glaser kirjoitti maanantai 3. elokuuta 2020:
> On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:
>
> > I conjecture that only few of the existing use cases rely on remote expansion.
>
> No, this is used all the time.
>
> scp remotehost:foo\* .
>
> (Unless rsync is available, but sadly that’s ? GPLv3 and ? not
> universally installed.)

And even if rsync *would* be there it is not really suited to fetching files without recursing into subdirectories... Hence case for scp.

- juice -


--
Sent from my SFOS/XperiaX
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The fact that scp has been carried for ages is part of its value
proposition. It’s going to work. Much as I am fond of my dd/cat/tar/smoke
signal hacks, scp is the standard.

A bit of a tangent: There is a security hole in scp, ssh, TLS, basically
everything running over IP. As transfer sizes have increased significantly,
the identity of a certain population of files being moved is increasingly
obvious due to byte count, compressed or otherwise.

No, you don’t get to pad every transfer out to the maximum possible size,
or delay transfers until you can aggregate payloads. Yes, somebody thought
of that.

There are limits.

On Tue, Jun 16, 2020 at 9:47 AM Jakub Jelen <jjelen@redhat.com> wrote:

> Hello all,
>
> I believe we all can agree that scp is ugly protocol carried for ages
> only for its simplicity of its usage and really no dependencies as it
> is installed together with every ssh client. But as we have seen
> recently, its simplicity and flexibility comes with security issues
> [1], it does not have great performance and there is really no
> development in there.
>
> Over the years, we still keep recommending people to use sftp instead,
> but its api is not that flexible and simple to be usable as a drop-in
> replacement in scripts nor for the occasional ad-hoc transfers of few
> files from one server to another.
>
> Before I start hacking, I would like to hear some opinions from others,
> whether this is something planned, welcomed or whether there are some
> good reasons to keep scp alive.
>
> I have in my mind three things/steps that would make it possible:
>
> * Update sftp client to be drop-in replacement for scp
> (and/or)
> * Change scp to use sftp internally
>
> * Modify sshd to use some compatibility "scpd" to support old clients
>
> and some time later
>
> * Remove scp or replace it with a symlink
>
>
> [1] http://www.openssh.com/txt/release-8.0
>
> Any ideas/comments/suggestions?
>
>
> Best regards,
> --
> Jakub Jelen
> Senior Software Engineer
> Security Technologies
> Red Hat, Inc.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser wrote:
> That would be the same as killing scp…

Better that... than having an inherently insecure scp... or at least
make it absolutely clear and rename it to i[nsecure]scp.

If the core functionality of a program (which is here probably the
"secure") is no longer given, then it's IMO better to rather cause
breakage (at least for old clients), than to keep going.


Cheers,
Chris.

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

On 8/3/20, 14:40, "openssh-unix-dev on behalf of Christoph Anton Mitterer" <openssh-unix-dev-bounces+uri=ll.mit.edu@mindrot.org on behalf of calestyo@scientia.net> wrote:
>> That would be the same as killing scp…
>
> Better that... than having an inherently insecure scp...

Not for me! Security provided by "scp" satisfies *my* use case.

> or at least
> make it absolutely clear and rename it to i[nsecure]scp.

Couldn't care less. There's a saying "You may call me 'pot' - just don't stick me into the oven"

> If the core functionality of a program (which is here probably the
> "secure") is no longer given, then it's IMO better to rather cause
> breakage (at least for old clients), than to keep going.

Again. For me that remote path expansion is not the "core". The "core" is the ability to do "cp" from one host within my security domain to another.

On Mon, 2020-08-03 at 18:44 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Again. For me that remote path expansion is not the "core". The
> "core" is the ability to do "cp" from one host within my security
> domain to another.

Well I guess mandatory should what most people want/can reasonably
expect/and are promised by a given program,... which is here most
likely secure copying over any line from/to an remote host (i.e.
including a scenario with rogue clients and/or servers).

I.e. it should not focus on what just certain people (who e.g. get
their security by other means) need... or even those who don't do their
homework, by e.g. not upgrading to recent versions/etc..



Cheers.

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

It seems to me that the "exploit" of

scp /sourcefile remoteserver:'`touch /tmp/exploit.sh`/targetfile'

can be simplified to

ssh remoteservertouch /tmp/exploit.sh

Or are we talking about using ssh in conjunction with some third-party
tool like "rssh", which claims to be able to grant scp access without
shell access?  If ssh itself has never claimed that was possible, then
maybe rssh should stop claiming that it is.

FWIW, I consider scp as a convenient shortcut for "ssh cat". Indeed, I
sometimes find myself transferring files which are multiple hops away
exactly like that:

ssh foo ssh bar cat baz >baz

If I want to transfer files to or from untrusted machines, or to offer
file transfer access without shell access, then that is what sftp is for.

Regards,

Brian.

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

On Mon, Aug 03, 2020 at 05:06:35PM +0000, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> wrote:

> I hear you - but it seems that the choice is between (a) limiting
> "scp" functionality to address the security vulnerability, and (b)
> killing "scp" altogether.
>
> I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .".
>
> Especially, since (almost always) I have equal privileges on both
> local and remote hosts, so in that case I just originate that "scp"
> from that remote. ;-)
>
> TNX

If you have equal privileges on both hosts, this isn't
a vulnerability. It's only a vulnerability in cases
where you have scp access to the remote host but you
are not supposed to have general ssh access (i.e. shell
access).

In such cases, this vulnerability can be mitigated by
the use of an ssh-specific command whitelisting control
such as:

github.com/raforg/sshdo (auto learn/unlearn policy, exact cmds, no regex)
github.com/daethnir/authprogs (manual policy, supports regex)

Disclaimer: I made sshdo so I'm biased. But if you
really think you need regex support and don't mind the
extra effort and the risk, authprogs will solve the
problem too. But I'd recommend reading the sshdo FAQ
before choosing.

cheers,
raf

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

On Mon, Aug 03, 2020 at 08:34:04PM +0200, Christoph Anton Mitterer <calestyo@scientia.net> wrote:

> On Mon, 2020-08-03 at 19:17 +0200, Thorsten Glaser wrote:
> > That would be the same as killing scp…
>
> Better that... than having an inherently insecure scp... or at least
> make it absolutely clear and rename it to i[nsecure]scp.

But it's not inherently insecure. For most cases, or at
least for the default case, where the users of scp are
also allowed to use ssh, this is not a vulnerability.
It only becomes insecure when general ssh access is not
allowed but scp access is.

> If the core functionality of a program (which is here probably the
> "secure") is no longer given, then it's IMO better to rather cause
> breakage (at least for old clients), than to keep going.

The core functionality is the encrypted transfer of
files. That is still there.

> Cheers,
> Chris.

cheers,
raf

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

Thank you - I wasn’t aware. Will check sshdo out.

Regards,
Uri

> On Aug 3, 2020, at 19:21, raf <ssh@raf.org> wrote:
>
> ?On Mon, Aug 03, 2020 at 05:06:35PM +0000, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> wrote:
>
>> I hear you - but it seems that the choice is between (a) limiting
>> "scp" functionality to address the security vulnerability, and (b)
>> killing "scp" altogether.
>>
>> I'd much prefer (a), even if it means I lose "scp remotehost:foo\* .".
>>
>> Especially, since (almost always) I have equal privileges on both
>> local and remote hosts, so in that case I just originate that "scp"
>> from that remote. ;-)
>>
>> TNX
>
> If you have equal privileges on both hosts, this isn't
> a vulnerability. It's only a vulnerability in cases
> where you have scp access to the remote host but you
> are not supposed to have general ssh access (i.e. shell
> access).
>
> In such cases, this vulnerability can be mitigated by
> the use of an ssh-specific command whitelisting control
> such as:
>
> github.com/raforg/sshdo (auto learn/unlearn policy, exact cmds, no regex)
> github.com/daethnir/authprogs (manual policy, supports regex)
>
> Disclaimer: I made sshdo so I'm biased. But if you
> really think you need regex support and don't mind the
> extra effort and the risk, authprogs will solve the
> problem too. But I'd recommend reading the sshdo FAQ
> before choosing.
>
> cheers,
> raf
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

The fundamental problem is that the command line syntax of sftp is not
great. There's no fundamental reason that can't be fixed, without even
changing the existing sftp protocol. But as long as scp (and rsync)
exist the motivation to actually make the sftp command line tool nicer
is so low that even though people have talked about it for 20 years, it
hasn't happened yet. (And even though it would require orders of
magnitude less effort than has been expended complaining about sftp &
scp over the last 20 years...)

I don't see an obvious way forward until someone decides to actually
make the sftp client nicer to use. (No need to even talk about it: just
show up with a finished version that does what scp does!)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

I don't understand the concern. I just tried

sftp remotehost:foo\* .

...and it did exactly what one would expect. It successfully retrieved all
files starting with foo.

It sure looks like globbing Just Works with sftp, so replacing the
underlying implementation of scp to use sftp should also work.

--Greg

On Mon, Aug 03, 2020 at 05:08:28PM +0200, Thorsten Glaser wrote:
> On Mon, 3 Aug 2020, Blumenthal, Uri - 0553 - MITLL wrote:
>
> > I conjecture that only few of the existing use cases rely on remote expansion.
>
> No, this is used all the time.
>
> scp remotehost:foo\* .
>
> (Unless rsync is available, but sadly that’s ? GPLv3 and ? not
> universally installed.)
>
> bye,
> //mirabilos
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser <t.glaser@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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@raf.org> wrote:

> On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser <
> t.glaser@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@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@gmail.com> wrote:

> On Tue, Aug 4, 2020 at 3:41 PM raf <ssh@raf.org> wrote:
>
> > On Tue, Aug 04, 2020 at 01:29:52AM +0200, Thorsten Glaser <
> > t.glaser@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

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

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

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

On Wed, 2020-08-05 at 08:33 +0100, Stuart Henderson wrote:
> 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).

At this moment, downloading files using sftp works the same as with
scp:

sftp localhost:/tmp/scp.c /tmp/tmp

Extending sftp to work the same way for uploading files to avoid the
above mess should be also pretty easy and would cover the most common
use cases.

Getting complete feature-parity with scp would be another feat though.

Regards,
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@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@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

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