Bug 72815 – net-misc/scponly: arbitrary command execution

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Matthias Geerdsen (RETIRED) 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:

rssh
	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.

scponly
	The author, Joe Boyle <[e-mail]>, 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
	before).

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.

Thanks,
Jason Wies


---------------------------------------------------------------------------

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 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 command.sh restricteduser@remotehost:/tmp/command.sh
	ssh restricteduser@remotehost 'scp -S /tmp/command.sh 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 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.

References:
	http://www.pizzashack.org/rssh/index.shtml
	http://www.sublimation.org/scponly/

-------------------------------------------------------

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

*** Bug 72816 has been marked as a duplicate of this bug. ***

[Comment 2 SpanKY 2004-11-29 19:59:08 UTC]

Created attachment 44970 [details]
scponly-4.0.ebuild

[Comment 3 Thierry Carrez (RETIRED) 2004-11-30 05:25:12 UTC]

This bug will track scponly only.

[Comment 4 Thierry Carrez (RETIRED) 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) 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) 2004-11-30 12:10:58 UTC]

Then we should wait for upstream :)

[Comment 7 SpanKY 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 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) 2004-12-02 07:30:51 UTC]

in cvs.

[Comment 10 Thierry Carrez (RETIRED) 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 (RETIRED) 2004-12-02 20:34:01 UTC]

It mentions rssh.

[Comment 12 Thierry Carrez (RETIRED) 2004-12-03 08:49:37 UTC]

GLSA 200412-01