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