[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20050115052426.GG8855@sophic.org>
Date: Sat, 15 Jan 2005 00:24:26 -0500
From: Derek Martin <code@...zashack.org>
To: rssh-discuss@...ts.sourceforge.net, bugtraq@...urityfocus.com,
openssh-unix-dev@...drot.org,
GNHLUG mailing list <discuss@...lug.org>,
"BLU Users' Group" <discuss@....Org>, secureshell@...urityfocus.com
Subject: Re: rssh and scponly arbitrary command execution
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 sourceforge.net site:
http://sourceforge.net/projects/rssh
All users of rssh should update to the latest release. The rssh
homepage is here:
http://www.pizzashack.org/rssh
Sorry for the slow response; I've had other priorities lately.
DM
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@...otehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp'
>
> scp command.sh restricteduser@...otehost:/tmp/command.sh
> ssh restricteduser@...otehost '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, 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:
> http://www.pizzashack.org/rssh/index.shtml
> http://www.sublimation.org/scponly/
>
>
> -------------------------------------------------------
> 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.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> rssh-discuss mailing list
> rssh-discuss@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rssh-discuss
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
Content of type "application/pgp-signature" skipped
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@...drot.org
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
Powered by blists - more mailing lists