rssh and scponly arbitrary command execution

Derek Martin code at pizzashack.org
Sat Jan 15 16:24:26 EST 2005


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 at remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp'
> 
>         scp command.sh restricteduser at remotehost:/tmp/command.sh
>         ssh restricteduser at 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, 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rssh-discuss

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050115/7b95688e/attachment-0002.bin 


More information about the openssh-unix-dev mailing list