If this were to be put to use in some kind of publicly accessible location,=
I wouldn't even consider this a fix for our problem. I do not believe in =
security through obscurity.
=

Now, where this comes into play is when we are dealing with sister companie=
s, trusted trading partners, etc... There's already a certain level of tr=
ust involved, and we're looking for something to prevent accidental file re=
location.
=

I understand that carefully tweaked data flow sent to the scp server side c=
ould cause data to be written to a location other than what's specified by =
the key. I have no questions that that could happen. =

=

Now the one thing that I would ask, is this, could a crafted scp connection=
(even when forced to run scp -t ) cause a file to be pulled down to the cl=
ient?
> Date: Fri, 7 Dec 2007 09:24:07 +0100> From: stuge-openssh-unix-dev@cdy.or=

g> To: guyverdh@hotmail.com> CC: openssh-unix-dev@mindrot.org> Subject: Re:=
scp -t - revisited.....> > On Thu, Dec 06, 2007 at 09:04:45PM -0600, Larry=
Becke wrote:> > *My apologies for mangling this, as I'm not a subscriber, =
and peter> > doesn't deign to reply to me as well as the list*> > Ah, you m=
entioned that you weren't subscribed back in the first> thread? Sorry, I fo=
rgot all about that.> > > >> What happens if you (within the scp protocol, =
not in the shell)> >> specify e.g. a new directory ../../../../../../../tmp=
/breakout ?> >> I would assume that /tmp/breakout is created.> > ..> > > Us=
ing scp as you showed, would not do anything to this method.> ..> > what re=
ally happens, as near as I've been able to figure out with> > the informati=
on that J.P. sent me, is that the client (or local)> > system executes the =
following.> > > > ssh -i key_file {remotehost} scp -d -t ../../../../../../=
.../../../../../tmp/breakout> > ..> > > The ssh key in question, is configur=
ed on the server to only run> > "scp -t /server/selected/path"> > > > This =
overrides the command that was sent by the scp client, and> > replaces it w=
ith what we want to happen.> > Right. Which is why I was careful to point o=
ut that specifying the> tmp path in the shell (such as in the example above=
) will not> expose the problem.> > > > Now, if the scp protocol can be expl=
oited some how beyond the open> > file / send contents, then we may have a =
problem - but that would> > be the case with scp in general.> > Spot on. sc=
p is not designed to confine a user to a given directory.> This is why you =
got a couple of different suggestions on how to solve> the problem in the f=
irst place.> > > >> I still believe there was a good reason for that argume=
nt.> > > > You're free to believe what you want, I found what I wanted - an=
d> > it works - very well.> > I don't have time to demonstrate/test my idea=
right now, but will> try to get back to you later today. If anyone else un=
derstands what I> mean and feels like hacking up an example, please do.> > =
> >>> (Wonders if this will be considered a bug to be fixed or quashed> >>>=

as it wasn't an intended *feature* of scp).... I hope not...> >> > >>It's =
just a side effect of the rcp/scp design.> > > > Which apparently neither o=
f us were 100% up on, and I was glad for> > the opportunity to learn someth=
ing new. I hope you did as well.> > I already knew how scp works (internall=
y) and I suppose noone else> suggested forcing the scp -t command because i=
t doesn't actually> provide what you initially asked for.> > > //Peter
__________________________________________________ _______________
Put your friends on the big screen with Windows Vista=AE + Windows Live=99.
http://www.microsoft.com/windows/sho...3DTXT_TAGLM_C=
PC_MediaCtr_bigscreen_102007
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev