Re: rssh and scponly arbitrary command execution

From: Derek Martin (
Date: 01/15/05

  • Next message: Darren Tucker: "Re: 'password-less' logins on solaris 2.5.1 boxen - subtle troubles"
    Date: Sat, 15 Jan 2005 00:24:26 -0500
    To:,,, GNHLUG mailing list <>, "BLU Users' Group" <discuss@Blu.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 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:
    > 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@remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp'
    > scp restricteduser@remotehost:/tmp/
    > ssh restricteduser@remotehost 'scp -S /tmp/ 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:
    > -------------------------------------------------------
    > 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

    Derek D. Martin
    GPG Key ID: 0x81CFE75D

  • Next message: Darren Tucker: "Re: 'password-less' logins on solaris 2.5.1 boxen - subtle troubles"