Hey. I'm also a bit concerned about this issue... On Tue, 2019-01-22 at 13:48 +1100, Damien Miller wrote:> Don't use > scp with untrusted servers.But that would effectively mean one has to toss scp. Reality is simply that most peers cannot be really trusted? just imagine all the administration work which is done from some user/admin's computer to countless servers (running services with a higher attack surface), cloud VMs (which one can generally not trust that much), etc.> Testing wanted and hopefully it will make the openssh-8.0 > release.Are there not going to be backports of the fixes to at least some of the older versions (or at least the current one)?> We don't consider the report relating to stderr to be a vulnerability > - > lots of stuff depends on stderr being present (e.g. login warning > banners that some people inexplicably love) and it's impractical for > scp to selectively process them. The machine you just logged into can > print junk to your screen, so what?Well I may miss some details, but especially for scp one wouldn't expect the same as from ssh (where it's clear that the remote terminal can print whatever it wants)... for scp people rather think the output is just systematic and no forgery can be done. It may not be a direct vulnerability, but taking over the user's terminal (to some extent) could still lead to attacks, if he believes that output.> We consider the last bug, relating to filename printing to be a > usability problem.Similar here... a forgery might be used for attacks, e.g. as what Sintonen writes, by hiding additionally transferred files. In general, I also don't think sftp is a viable replacement; using it on the command line to just transfer single files is much less handy than using scp. So isn't it possibly to fully fix scp? And maybe in addition to prevent scp from overwriting existing files? But if it cannot be secured... one should probably reamed it (in)scp ... mark it legacy and drop it sooner or later. Cheers, Chris.
On Wed, Jan 23, 2019 at 06:29:29PM +0100, Christoph Anton Mitterer wrote:> So isn't it possibly to fully fix scp?IMO a complete fix should involve converting scp to use the SFTP protocol under the hood. PuTTY's pscp takes this approach. I started working on a similar patch to OpenSSH some years ago but never got around to finishing it. (Yes, a traditional scp client invokes scp on the server as part of its protocol; but it passes special -f or -t options when it does so, so that doesn't preclude having scp speak the SFTP protocol when invoked in the ordinary way.) -- Colin Watson [cjwatson at debian.org]
I worked on a proposal like this a few years back (including proof of concept code).? I taught sftp to have an scp personality (closer to scp2 than scp), and it was rejected by the higher ups.? It may have been the dual-personality issue, but I know the scp2 concept was also rejected at the time as it was stated there should be one transfer tool. But the only way to drag scp into this century is pretty much a scp2 style interface.? As mimic all the stupidity of shell escape handling for wildcard matching while using sftp protocol is asking for brokenness in strange ways.? This is why scp2 was created by SSH Corp. Ben Colin Watson wrote on 1/23/19 12:00 PM:> On Wed, Jan 23, 2019 at 06:29:29PM +0100, Christoph Anton Mitterer wrote: >> So isn't it possibly to fully fix scp? > IMO a complete fix should involve converting scp to use the SFTP > protocol under the hood. PuTTY's pscp takes this approach. I started > working on a similar patch to OpenSSH some years ago but never got > around to finishing it. > > (Yes, a traditional scp client invokes scp on the server as part of its > protocol; but it passes special -f or -t options when it does so, so > that doesn't preclude having scp speak the SFTP protocol when invoked in > the ordinary way.) >
On Wed, 2019-01-23 at 18:00 +0000, Colin Watson wrote:> IMO a complete fix should involve converting scp to use the SFTP > protocol under the hood.I've had thought about the same but didn't dare to propose it ;-) The problem IMO is: Either such scp would silently fall back to the "old" scp protocol, if it talks to an "old" server... (in which case the whole thing doesn't make any sense). Or compatibility would be broken. I (personally) wouldn't mind that,... there are too many nice features one would like to see in scp for long and which are allegedly not possible because of the protocol... being safe, asking for confirmation on overwriting, XATTRs, ACLs,... But whatever it is: most people I know don't like the sftp interface,... and it shouldn't be assumed that remote servers are trustworthy (even if they actually are). Cheers, Chris.