*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*
=

On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:>> This leads m=
e to believe that using the scp -t>> /some/path/to/a/directory command=3D =
in the authorized_keys file>> causes scp to forget/ignore everything after =
the remote hostname.>There is one more step between the remote scp (run wit=
h -t) and the>"remote filename" as specified in the local shell: The local =
scp.
You're right as long as the scp client has the power to do anything, beyond=
send the file names/content. However, with this method, the local scp is =
powerless.
>> This gives us almost exactly what we were looking for>I think that depen=

ds on the local scp program.
=

Sorry, not with this method.>What happens if you (within the scp protocol, =
not in the shell)>specify e.g. a new directory ../../../../../../../tmp/bre=
akout ?>I would assume that /tmp/breakout is created.
Again, not with this method.
>If your local scp program is trusted then you're all set. But if that>was =

the case why bother with locking down the server?
Unfortunately (or in my case, fortunately), that's not how scp works.
=

Using scp as you showed, would not do anything to this method.
=

The reason being is as follows...
=

scp -i key_file localfile remotehost:../../../../../../../../../../../tmp=
/breakout
=

what really happens, as near as I've been able to figure out with the infor=
mation 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
=

now - normally this would cause the effect that you mentioned - except for =
one minor little thing.
=

The ssh key in question, is configured on the server to only run "scp -t /s=
erver/selected/path"
=

This overrides the command that was sent by the scp client, and replaces it=
with what we want to happen.
=

No directory selection, it gets rid of all your carefully crafted pathing e=
xploit attempts - they're all gone, as though they never existed.
=

Now, the scp -t starts the scp server service in receive mode (this is an a=
ssumption on my part), waiting for the client to send the commands needed t=
o create the file and it's contents (or multiple files and their contents).
=

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.
=

Now, if the scp protocol can be exploited some how beyond the open file / s=
end contents, then we may have a problem - but that would be the case with =
scp in general.
=

I would also assume that using another key to put the scp server side into =
send mode - ie scp -f /server/selected/path - would restrict downloads =
from the specified directory, again, regardless of what the client asked fo=
r.
>> Like I said, I'm sitting here laughing right now, mostly because it>> wa=

s a lot of wasted effort on all sides to argue (or discuss with>> pointed s=
tatements) over something that already existed, even if it>> wasn't known o=
r documented.>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.>> (Wonders if this will be considered a bug to be fixed or qua=
shed 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 oppo=
rtunity to learn something new. I hope you did as well.>//Peter
LB
__________________________________________________ _______________
You keep typing, we keep giving. Download Messenger and join the i=92m Init=
iative now.
http://im.live.com/messenger/im/home/?source=3DTAGLM
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev