This is a discussion on Re: scp -t - revisited..... - openssh ; On 2007-12-07 03:04, Larry Becke wrote: > This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer ...
On 2007-12-07 03:04, Larry Becke wrote:
> This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer commands.
If that's the case, it's by accident. If you're happy with accidental
security, and nobody needs to analyze scp or write additional code for
you, then great! we're done here.
> Now, if the scp protocol can be exploited some how beyond the open file / send contents, then we may have a problem - but that would be the case with scp in general.
There would be no problem with scp in general in that case, because it
is not a design goal of scp to keep the user from writing to certain
files. That constraint is left up to features of the native operating
environment, e.g. filesystem permissions, which behave deterministically
and require no additional analysis. Those who want to have reliable
security don't rely on undocumented, unproven behaviour that is an
accidental and possibly transitory side-effect of one particular
implementation. I thought we explained all that before, but hey, if
you're happy, I'm happy. :^)
NOAA Computer Incident Response Team (N-CIRT)
"Never try to retrieve anything from a bear."--National Park Service
openssh-unix-dev mailing list