vulnerabilities in scponly

["Derek D. Martin" <ddm () pizzashack org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BACKGROUND:

scponly is a replacement shell for the purpose of providing scp and
sftp access to an account, without allowing shell access.  It can be
downloaded here:

  http://www.sublimation.org/scponly/

DETAILS:

Circumvention of access limitations through user's sshd environment
files

scponly makes no effort to verify the path to the scp or sftp-server
executables before it executes them, and uses system() to do so.

If the server administrator makes no effort to restrict access to the
user's .ssh directory, the user can upload a file with a custom
environment to $HOME/.ssh/environment.  Subsequently, the user can
upload a script or program to run arbitrary commands, such as to
change their login shell, or what have you.

For example, the user could scp the following to
$HOME/.ssh/environment:

    # ssh environment
    PATH=/home/myhomedir/:/usr/bin:/bin
    #end

Subsequently, the user could upload the following file to their home
directory, and call it scp:

    #!/bin/sh
    
    echo "I'm a bad boy" > /tmp/exploit
    /usr/bin/scp $@

    # end

When they next scp a file:

    [root@restricted /tmp]
    # ls -l
    total 24
    -rw-r--r--    1 bonehead bonehead       14 Aug 19 22:46 exploit
    [root@restricted /tmp]
    # cat exploit
    I'm a bad boy

Provided they're careful about output of their command, with the above
script the file still gets copied and anyone watching over their
shoulder is none the wiser.  Obviously this could be replaced with any
arbitrary command; this provides the user with a means of running
arbitrary commands by simply uploading a file.  Another neat trick is:

  echo "mypassword" | chsh -s /bin/bash

Now the user can log in with ssh, assuming chsh allows users to change
their own shells.

Tested and verified on Red Hat 7.1, but should work on any system
running the OpenSSH sshd server.

Additionally, some versions of the OpenSSH sshd(8) man page claim that
at start-up, sshd will execute commands in $HOME/.ssh/rc using
/bin/sh, rather than with the user's shell as listed in /etc/passwd.
The man page on my system says this, even though in practice the
version of sshd I have installed actually does use the user's shell.
However, if this is *NOT* the case, the user could execute arbitrary
commands by uploading a file to $HOME/.ssh/rc.

Finally, though effort is made to remove shell metacharacters from the
input, scponly uses system() to execute commands.  Also wildcards are
allowed.  In some environments, it may be possible to exploit this
situation.  No verified exploit.


SOLUTION:

There are several possible ways to "fix" these problems, some perhaps
better than others.

1.  Limit the user's ability to affect their environment

The first is more a workaround than a solution, but should be
effective.  This is the route the author has chosen to go, for the
moment, while he works on other fixes.  The ability of the user to
circumvent scponly is dependent upon their ability to manipulate their
environment, by uploading files to specific locations in their .ssh
directory.

The system administrator can prevent this by making the user's home
directory non-writable to the user.  In order to provide file upload
to the user, a user-writable directory must be provided for that
purpose.

Some may feel this is too restrictive; some may feel that creating
.ssh/ and making it unwritable to the user is sufficient.  It isn't.
If the user has write access to their home directory, the user can log
in via sftp, and simply remove the .ssh directory if it is empty, or
rename it if it is not, regardless of who owns it or what its
permissions are.  The only way to prevent them from doing this is to
make their home directory non-writable.

This will prevent the user from being able to modify their environment
files, preventing the exploit.

Depending on how the call to system() can be exploited, if it can be
at all, this may or may not solve that problem.

The author's update involves documenting the problem, and updating the
installation to include some chown commands.  The author does intend
to remove the call to system() in the immediate future; but with no
threat of a known exploit which was not fixable in doing the above,
was not concerned that I wait to release this vulnerability before
having the opportunity to do so.

2.  Fix the code

These problems can be eliminated by forcing the use of the "correct"
path for the scp or sftp-server binaries on the restricted host, and
by using execv() to execute the programs.  The correct paths can be
either provided by configuration file, or compiled in.  Eliminating
the reliance on the user's environment prevents them from being able
to make modifications that affect the program.  

Incidentally, I became aware of the vulnerabilities in scponly after
having written my own program, called rssh, to do essentially the same
thing.  This is the approach I took.  Unfortunately, if sshd on the
system in question does in fact use /bin/sh to execute programs in
$HOME/.ssh/rc, there's not much you can do programatically, and the
workaround in part 1 must be used.  I note this in the manpage for
rssh.  The limitation is that by the time scponly (or rssh) runs, sshd
has already allowed the user to execute commands.

For the interested, rssh can be downloaded here:

  http://www.pizzashack.org/rssh/

I encourage the bugtraq community to poke holes in it.

3. "Fix" sshd

While not technically broken, it surprises me that there is no option
in OpenSSH's sshd to ignore user environment variables, especially
since they do have options to ignore other user files (specifically
.rhosts and .ssh/known_hosts).  Used in conjunction with such an
option, all of the problems above would be eliminated.  For this sort
of functionality, the combination of 2 and 3 is probably the ideal
solution.


- -- 
Derek Martin               ddm () pizzashack org    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Yb55djdlQoHP510RApvdAJ0XnFA/v2R67BwyErK9ALKzkj+dFQCguRs9
FMXFmY2EwrZpR2qvsN+7tyg=
=lVLH
-----END PGP SIGNATURE-----