Blumenthal, Uri - 0553 - MITLL
2020-Aug-03 17:06 UTC
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>
Thorsten Glaser
2020-Aug-03 17:17 UTC
Deprecation of scp protocol and improving sftp client
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
Blumenthal, Uri - 0553 - MITLL
2020-Aug-03 17:27 UTC
Deprecation of scp protocol and improving sftp client
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>
Christoph Anton Mitterer
2020-Aug-03 18:34 UTC
Deprecation of scp protocol and improving sftp client
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. ;-) > > TNXIf 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
Blumenthal, Uri - 0553 - MITLL
2020-Aug-03 23:26 UTC
Deprecation of scp protocol and improving sftp client
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>
Thorsten Glaser
2020-Aug-03 23:29 UTC
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!
Apparently Analagous Threads
- Deprecation of scp protocol and improving sftp client
- Deprecation of scp protocol and improving sftp client
- Deprecation of scp protocol and improving sftp client
- [Bug 2287] New: AuthorizedKeysCommandUser should have it's default documented
- [Bug 2354] New: please document that PermitRootLogin really checks for uid=0