Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 72816 - app-shells/rssh arbitrary command execution
Summary: app-shells/rssh arbitrary command execution
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo Security
Whiteboard: B1 [glsa] jaervosz
Depends on:
Reported: 2004-11-29 07:35 UTC by Sune Kloppenborg Jeppesen
Modified: 2005-01-16 13:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen gentoo-dev 2004-11-29 07:35:13 UTC
Projects: rssh and scponly
Class: Arbitrary command execution
Public disclosure date: Thursday Dec. 02, 2004

This message is being sent to rssh and scponly package maintainers as well
as the Debian security team. Most likely I've left someone out, so could
someone (probably a Debian security team member) with access to vendor-sec
(or whatever the current vendor security distribution method is) please
forward this on to the other vendors and distributors.  Thanks.

The vulnerability is described in detail below.  The bottom line for package
maintainers is this:

        The author has stopped working on the program and has no interest in
        providing a fix.  He is willing to work with anyone who wants to
        take over maintainership.  Given that the solution is most likely
        not going to be simple to implement, rssh is currently unmaintained,
        and the vulnerability affects almost all uses of rssh, distributors
        may wish to remove it from their archives until a comprehensive fix
        is available.  That said, an ambitious package maintainer that wants
        to have a look at fixing the source code may find that a reasonable
        solution is only an afternoon's worth of work.  I haven't look at it
        closely enough myself to say for sure.

        The author, Joe Boyle <>, has committed to
        providing a new version that addresses the vulnerability.  He will
        follow up with the scponly package maintainers to provide the new
        source code for packaging before the public disclosure date if the
        new version is available before then (it should be available well

Dec. 02 is the agreed upon date for public posting of the notice below and
 for the new version of scponly to be publicly released.  I think that is a
 reasonable timeline but if anyone strongly objects do let me know.

Jason Wies


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 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 restricteduser@remotehost:/tmp/
        ssh restricteduser@remotehost 'scp -S /tmp/ localhost:/dev/null


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 that addresses
the current problem.  Distributor updates have been coordinated with this
posting and should be made available shortly.

I think the long-term solution for those needing a highly secure restricted
shell is not to allow options to commands at all, but to instead store the
entire command line on the remote host and allow the user only to select
from the list of stored command lines.  I'm not aware of any software that
offers this capability today.

Comment 1 Matthias Geerdsen (RETIRED) gentoo-dev 2004-11-29 07:37:34 UTC

*** This bug has been marked as a duplicate of 72815 ***
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2004-11-30 05:24:11 UTC
Thos two bugs are likely to get resolved at different times.
Reopening and using this bug to track rssh.
Comment 3 SpanKY gentoo-dev 2004-12-02 18:26:27 UTC
the debian people are talking of just punting it from their repo since the upstream author has already said he's pretty much abandoned the package due to lack of time
Comment 4 Sune Kloppenborg Jeppesen gentoo-dev 2004-12-02 20:34:34 UTC
Opening up this is public now.
Comment 5 Kurt Lieber (RETIRED) gentoo-dev 2004-12-03 05:44:12 UTC
if it's vulnerable and abandoned by upstream, we should punt it as well.
Comment 6 Kurt Lieber (RETIRED) gentoo-dev 2004-12-03 05:55:23 UTC
hard masked in package.mask.
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2004-12-03 08:48:48 UTC
GLSA 200412-01 masks rssh
Bug kept open since it's still in the tree
Comment 8 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-15 11:17:53 UTC
Upstream fix:
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2005-01-15 11:21:32 UTC
vapier, max : feel free to bump and remove package mask.
Should be released as a GLSA 200412-01 update.
Comment 10 SpanKY gentoo-dev 2005-01-16 11:10:36 UTC
2.2.3 now in portage
Comment 11 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-16 13:04:48 UTC
Thx SpanKY.

GLSA 200412-01 updated.