scp exploit

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi Everyone,
  I was looking at the patch on OpenBSD's website and have understood
it to mean that I can pass commands through scp to the remote server.
This is not huge since I have remote access, but I am curious about the
"what if I have x user restricted".  Doing some testing I found that
something along the lines of scp filename "hostname:/dir;somecommand"
would execute with my privileges on the server.

Looking further at the patch, both on and Redhat Bugtraq, I
found that the example (on RH BugTraq) specified something like:

Steps to Reproduce:
1.touch foo\ bar
2.mkdir somedir
3.scp foo\ bar somedir

Actual results:
cp: cannot stat `foo': No such file or directory
cp: cannot stat `bar': No such file or directory

Now, this didn't work for me.  Basically, the shell kept escaping the
'' and I would end up with a foobar :) No pun intended.

I then applied the patch and ran the newly built sshd server at port
2222 and then used the newly built scp to transfer a file with the
somecommand in the string, and it still executed.

I am not very good with C, but I looked at scp.c/misc.h and a few other
files, and it doesn't look like there is any checking for a command
embedded in the string.

Am I reading this wrong?  Or is it true that I am a complete moron?

Y'know, I always suspected the latter. :)

Thanks for any light you can shed for a curious admin....

Re: scp exploit

I just downloaded the latest version of OpenSSH (4.3) and it (scp) also
exibits this behavior.  Is there any way to restrict a user from
passing in a command in the filename string?  Again, this would be in a
"restricted" setting where you may have scripts running and you only
want scp, but not necessarily the ability to pass in commands.

Reading (what I can) through the source, it seems that the ssh program
is doing the actual work for scp.

This is the code (I think is relative):
char *ssh_program = _PATH_SSH_PROGRAM; (which is included from
pathnames.h and is pointer (am I right on this one) to the

this is then used a few times and eventually passed to:
execvp(ssh_program, args.list);

When I run scp in verbose mode I see a:
debug1: Sending command: scp -v -t /tmp;touch /tmp/target

The "Sending command:" is defined in ssh.c on line 940.  I definitely
see the benefits to using ssh to do the legwork, but could I patch scp
so that it checks the args for a ";" in the string so as not to send
additional data through ssh (which of course will execute it).  This is
the code from 940:
 debug("Sending command: %.*s", len, (u_char *)buffer_ptr(&command));

Just out of curiousity though.  I have used rcp, but never thought to
use it this way.  Is this a holdover from those days?

Again, thanks for indulging my curiousity.

Re: scp exploit

Quoted text here. Click to load it

scp probably should quote that, but that's not the problem.  If the
server's running a restricted shell then the shell ought to filter the
";", for a regular shell it's no different from a security perspective
from sending a command string via ssh containing ";" (or any other shell
metacharacter for that matter).

The problem was that the local scp could be caused to execute a command
with the privilege of the user running scp by bobytrapping a directory
with files containing shell metacharacters.

Quoted text here. Click to load it

You could, but this kind of filtering on the client side would be useless
as a security measure.

Quoted text here. Click to load it

Yes.  The same code is in OpenBSD's rcp (and it probably goes back as
far as 4.2BSD).

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: scp exploit

Darren Tucker wrote:

Quoted text here. Click to load it

Yeah, there are a lot of issues with scp. If you really want robust and
limited access file transfer, without allowing the sender to have shell
access on the server, scp is usually not the right approach.

Re: scp exploit

Thanks for the responses!

Ok, so.  let me wrap my head around this.  If a user tries to copy a
local file using scp (isn't that what we use cp for), then
another user could boobytrap, say /tmp.  The user copying some
directory out of tmp, or series of files from /tmp will then risk the
possibily of accidentally executing something in that directory, due to
metacharaters being embedded in the filename.

This begs a couple of questions.

First, who would using scp for local file copying, and why?

Second, I have seen something on the web about "scponly", is this a
decent replacement for scp?  I also saw lots of security bulletins.

Also, I am familiar with meta characters, but would like to read up
more on them after this discussion, any good links you can point me to?
 I'll google it, but maybe you guys have some good articles stored

Thanks for the information, very enlightening.


Re: scp exploit

Quoted text here. Click to load it

Here's a description of not quite the same thing.

The outline of the problem is that executing commands with some
user input can be done in multiple ways - not all equally suitable
and in some cases frankly unsafe.

Say the user supplied an email address to your program and you used
sendmail to send an email to the user-supplied address.

You could use a shell to run "/usr/lib/sendmail $useraddr" but then
you'd be in trouble if $useraddr="me@here; rm -rf /" .  Especially
if it ran as root.  :)
In this example you can check the user-supplied data for valid content
but only because you know what you expect it to contain.

A Perl programmer might do exec("/usr/lib/sendmail","$useraddr");
There's a similar arrangement in C.  Neither of these uses a shell
so the ';' is not used to end a command and start a new one.

Or some form of exec() on "/usr/lib/sendmail", "-oi", "-t"
might be even better and then provide $useraddr in the input to
the sendmail process so it never gets a chance to interfere on
the command-line at all.   This still calls for some care in what you
allow as it could be defined for multiple users or other mischief.

Lots of articles on secure programming cover this sort of stuff and
if the bits of the thread I've read are not misleading the concern
here is about how the command-lines to scp are produced and executed
(at both ends) using (in place of your * characters) whatever filenames
happen to be present.

Elvis Notargiacomo  master AT barefaced DOT cheek /
    Powergen write "Why not stay with us" - let me count the ways!

Re: scp exploit

Quoted text here. Click to load it

Or local -> remote.

Quoted text here. Click to load it

See above.

Those restricted shells should prevent passing of shell metacharacters
to remote processes, which is a very similar but unrelated issue.

Darren Tucker (dtucker at
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Site Timeline