scp -t - revisited.....

[Larry Becke]

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 companies, trusted trading partners, etc...   There's already a certain level of trust involved, and we're looking for something to prevent accidental file relocation.
 
I understand that carefully tweaked data flow sent to the scp server side could 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 client?
> Date: Fri, 7 Dec 2007 09:24:07 +0100> From: stuge-openssh-unix-dev at cdy.org> To: guyverdh at hotmail.com> CC: openssh-unix-dev at 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 mentioned that you weren't subscribed back in the first> thread? Sorry, I forgot 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.> > ..> > > Using scp as you showed, would not do anything to this method.> ..> > what really happens, as near as I've been able to figure out with> > the information 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 configured 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 with what we want to happen.> > Right. Which is why I was careful to point out 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 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.> > Spot on. scp 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 first place.> > > >> I still believe there was a good reason for that argument.> > > > You're free to believe what you want, I found what I wanted - and> > 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 understands 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 of us were 100% up on, and I was glad for> > the opportunity to learn something new. I hope you did as well.> > I already knew how scp works (internally) and I suppose noone else> suggested forcing the scp -t command because it doesn't actually> provide what you initially asked for.> > > //Peter
_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007