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 <firstname.lastname@example.org>, 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.
All operating systems
All operating systems
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
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:
- 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 --"
scp command.sh restricteduser@remotehost:/tmp/command.sh
ssh restricteduser@remotehost 'scp -S /tmp/command.sh 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.
*** This bug has been marked as a duplicate of 72815 ***
Thos two bugs are likely to get resolved at different times.
Reopening and using this bug to track rssh.
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
Opening up this is public now.
if it's vulnerable and abandoned by upstream, we should punt it as well.
hard masked in package.mask.
GLSA 200412-01 masks rssh
Bug kept open since it's still in the tree
Upstream fix: http://sourceforge.net/project/showfiles.php?group_id=65349
vapier, max : feel free to bump and remove package mask.
Should be released as a GLSA 200412-01 update.
2.2.3 now in portage
GLSA 200412-01 updated.