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

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/f18eb2b6/attachment-0001.p7s>

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

On 8/3/20, 13:18, "Thorsten Glaser" <t.glaser at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/b1e0166c/attachment.p7s>

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.

On Mon, Aug 03, 2020 at 05:06:35PM +0000, "Blumenthal, Uri - 0553 -
MITLL" <uri at 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

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

Regards,
Uri
> On Aug 3, 2020, at 19:21, raf <ssh at raf.org> wrote:
> 
> ?On Mon, Aug 03, 2020 at 05:06:35PM +0000, "Blumenthal, Uri - 0553 -
MITLL" <uri at 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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5874 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200803/10f83dab/attachment.p7s>

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!