Status of SCP vulnerability

[Christoph Anton Mitterer]

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.