Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 72815 - net-misc/scponly: arbitrary command execution
Summary: net-misc/scponly: arbitrary command execution
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa] 20041202
Depends on:
Reported: 2004-11-29 07:26 UTC by Matthias Geerdsen (RETIRED)
Modified: 2004-12-03 08:49 UTC (History)
1 user (show)

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

scponly-4.0.ebuild (scponly-4.0.ebuild,3.00 KB, text/plain)
2004-11-29 19:59 UTC, SpanKY
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Geerdsen (RETIRED) gentoo-dev 2004-11-29 07:26:08 UTC
From Jason Wies:

Subject: rssh and scponly arbitrary command execution
Date: Saturday 27 November 2004 08:16 pm

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
*** Bug 72816 has been marked as a duplicate of this bug. ***
Comment 2 SpanKY gentoo-dev 2004-11-29 19:59:08 UTC
Created attachment 44970 [details]
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2004-11-30 05:25:12 UTC
This bug will track scponly only.
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2004-11-30 05:27:50 UTC
vapier/matsuu: would you say it's good enough to be committed as stable directly for x86 and amd64 on release date ? Or do you prefer we call selected people from both arhes to test and give their go ?
Comment 5 MATSUU Takuto (RETIRED) gentoo-dev 2004-11-30 07:15:22 UTC
scponly-4.0 has not been released yet.
I have amd64 machine. If it is released, I try it immediately.
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2004-11-30 12:10:58 UTC
Then we should wait for upstream :)
Comment 7 SpanKY gentoo-dev 2004-11-30 14:41:03 UTC
it hasnt been released because they're coordinating with the security announcement :P

i tested the attached ebuild on x86 ... should be fine for straight stable loving
Comment 8 SpanKY gentoo-dev 2004-12-02 06:10:53 UTC
vuln has been disclosed ... matsuu, could you please add the ebuild to portage so we can release a GLSA ?
Comment 9 MATSUU Takuto (RETIRED) gentoo-dev 2004-12-02 07:30:51 UTC
in cvs.
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2004-12-02 08:29:42 UTC
Stable and GLSA drafted.

I've not seen the annoucement, but if it mentions rssh, then it should be masked and the GLSA should speak of both...
Comment 11 Sune Kloppenborg Jeppesen gentoo-dev 2004-12-02 20:34:01 UTC
It mentions rssh.
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2004-12-03 08:49:37 UTC
GLSA 200412-01