Back to list
rssh and scponly arbitrary command execution
Dec 02 2004 01:51PM
Jason Wies (jason xc net)
Re: rssh and scponly arbitrary command execution
Jan 15 2005 05:24AM
Derek Martin (code pizzashack org)
I just released rssh version 2.2.3 to fix the problem detailed below.
I haven't had time to update my website yet, and my Internet acess is
quite limited these days (hence the terse announcement), so I probably
won't get to that for a while. However, rssh 2.2.3 is available from
the sourceforge.net site:
All users of rssh should update to the latest release. The rssh
homepage is here:
Sorry for the slow response; I've had other priorities lately.
On Thu, Dec 02, 2004 at 01:51:43PM +0000, Jason Wies wrote:
> Vulnerable applications:
> All versions
> All operating systems
> All versions
> All operating systems
> Not vulnerable:
> 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
> 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.
> ssh restricteduser@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp'
> scp command.sh restricteduser@remotehost:/tmp/command.sh
> ssh restricteduser@remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp'
> 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.
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> rssh-discuss mailing list
> rssh-discuss (at) lists.sourceforge (dot) net [email concealed]
Derek D. Martin
GPG Key ID: 0x81CFE75D
[ reply ]
Copyright 2010, SecurityFocus