Message-ID: <20041202135143.GA7105@xc.net>
Date: Thu, 2 Dec 2004 13:51:43 +0000
From: Jason Wies <jason@...net>
To: bugtraq@...urityfocus.com
Cc: rssh-discuss@...ts.sourceforge.net
Subject: rssh and scponly arbitrary command execution


Vulnerable applications:

        rssh
                All versions
                All operating systems
        scponly
                All versions
                All operating systems

Not vulnerable:

Discussion:

rssh and scponly are restricted shells that are designed to allow execution
only of certain preset programs.  Both are used to grant a user the ability
to transfer files to and from a remote host without granting full shell
access.  Due to the fact that most of the preset programs offer options that
execute other programs, arbitrary command execution on the remote host is
possible.

rssh allows any of five predefined programs to be executed on the remote
host depending on the configuration.  Those that are known to be vulnerable
in combination with the techniques described in this posting are marked with
an asterisk.
- scp*
- sftp-server
- cvs
- rdist*
- rsync*

scponly allows a number of predefined programs to be executed on the remote
host depending on compile-time options.  Those that are known to be
vulnerable when used with scponly:
- scp
- rsync
- unison (*untested)

The program execution options that these programs offer:

rdist -P <program>
rsync -e <program>
scp -S <program>
unison -rshcmd <program>
unison -sshcmd <program>

These options allow the user to specify the location of the shell to use
when connecting to the remote host.  No restriction is placed on what
programs may be specified by these options, and rssh and scponly do not
filter these options out.  The end result is that although a user may be
restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can
in fact execute any program using /usr/bin/scp -S <program>.

The problem is compounded when you recognize that the main use of rssh and
scponly is to allow file transfers, which in turn allows a malicious user to
transfer and execute entire custom scripts on the remote machine.

rssh with sftp-server does not appear to be vulnerable.  rssh with cvs is
also not vulnerable using these techniques.  However, it is quite probable
that a malicious user could check out a carefully crafted CVS repository and
execute arbitrary commands using CVS's hooks interface.

Examples:

        ssh restricteduser@...otehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp'

        scp command.sh restricteduser@...otehost:/tmp/command.sh
        ssh restricteduser@...otehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp'

Solution:

There are no workarounds for this problem.

I have talked with the author of rssh, Derek Martin.  He is currently
indisposed for an indefinite period of time due to changing countries and
having no permanent home at the present moment.  Moreover he has other
priorities and has lost interest in maintaining the program.  He has offered
to assist anyone who would like to take over maintainership of rssh, but he
does not intend to provide a fix for the current problem.  Given this fact,
I would strongly recommend against using rssh at this time.

The author of scponly, Joe Boyle, has prepared a new release, version 4.0,
that addresses the current problem.

Distributor updates have been coordinated with this posting and should be
available soon.

I think the long-term solution for those needing a highly secure restricted
shell is to allow granular configuration by administrators of which options
and arguments, if any, are allowed to be specified for which programs.  In
the most restricted case entire command lines would be stored on the remote
host and the client would be allowed only to select from the list of
available command lines.  I'm not aware of any software that offers these
capabilities today.

References:
        http://www.pizzashack.org/rssh/index.shtml
        http://www.sublimation.org/scponly/

Powered by blists - more mailing lists