scp exploit - SSH

This is a discussion on scp exploit - SSH ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: scp exploit

  1. scp exploit

    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 OpenBSD.org 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....


  2. 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
    _PATH_SSH_PROGRAM)

    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.


  3. Re: scp exploit

    On 2006-02-15, Jesse Charbneau wrote:
    > 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
    > _PATH_SSH_PROGRAM)
    >
    > 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


    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.

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


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

    > 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?


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

    --
    Darren Tucker (dtucker at zip.com.au)
    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.

  4. Re: scp exploit

    Darren Tucker wrote:
    > On 2006-02-15, Jesse Charbneau wrote:


    >> 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?

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


    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.



  5. 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
    away.

    Thanks for the information, very enlightening.

    Jess


  6. Re: scp exploit

    On 2006-02-17, Jesse Charbneau wrote:

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


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


    Here's a description of not quite the same thing.
    http://www.sunmanagers.org/archives/1994/0509.html

    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
    http://www.notatla.org.uk/goen/
    Powergen write "Why not stay with us" - let me count the ways!

  7. Re: scp exploit

    On 2006-02-17, Jesse Charbneau wrote:
    > 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),


    Or local -> remote.

    > 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?


    See above.

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


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

    --
    Darren Tucker (dtucker at zip.com.au)
    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.

+ Reply to Thread