- home of pizzacode

rssh security implications

rssh home
Japanese translation
mailing list
future development

Jul 17 2003

Note: this page is mostly outdated. If you are using the latest rssh with OpenSSH >= 3.5, all you need to know is that you should configure PermitUserEnvironment in your sshd_config to no. If you do not do this, it will be possible for users to circumvent rssh. It is important to understand that this is not because of any flaw in rssh. Keep reading for details...

Aug 22 2002

The details of the problem, including a description of how a user might exploit the problem, are discussed below. It is currently not completely possible to prevent users from circumventing rssh to gain access to the restricted system, unless one of two precautions is taken:

  • the rssh binary is compiled statically
  • efforts are made to prevent the restricted users' environment files from being user-modifiable
In practice, the latter means that an rssh user's home directory must not be writable to the user, nor must their .ssh directory (if it exists) be writable. It is not sufficient to limit the .ssh directory, as users could use sftp to remove or rename the .ssh directory, and create a new one which is writable by them. Note that this means they can not own their home directory either, as if they do they can use sftp to chmod it. Alternately on Linux systems using file systems which support the chattr command, you could chattr +i the .ssh directory.

For this reason, as of rssh v0.9.3, the binary is compiled statically by default. Note that this results in a very large binary (>400k), unlike when rssh is compiled and linked dynamically. Since v1.0.0, there is a configure option to disable static linking. See the output of configure --help for details.

Note that it appears to be impossible to build a working rssh statically on Solaris, though it may work if you are not running it on systems patched to prevent executable stacks and/or heaps. Building static binaries on Solaris is hard, because some of their static library calls reference the dlopen() family of functions, which strikes me as incredibly brain-dead. In many cases, it can be worked around by providing stub functions for that family of functions, but some who've tried to do this with rssh have reported that the resulting binary segfaults. If you are trying to use rssh on Solaris, I strongly suggest you upgrade to OpenSSH 3.5 (see below). Otherwise, you will have to manually disable static compilation at configure time, and risk your users circumventing rssh.

Please note, the flaw is not in rssh itself. The problem is that the OpenSSH Project's sshd (in versions prior to OpenSSH 3.5) reads $HOME/.ssh/environment when a user first connects (regardless of whether it's via ssh, scp, or sftp), allowing users to set variables in their environment. A user could scp a file to that location containing a line that sets variables such as LD_LIBRARY_PATH and/or LD_PRELOAD, allowing the user to cause binaries exec()'d by the sshd daemon to be dynamically linked against libraries of their choosing. This means that users can cause rssh itself to execute arbitrary code, and the only thing that you can do to prevent this attack is to control users' environments, and make absolutely sure they can not write to their .ssh directory.

In OpenSSH 3.4 and before, there is no way to prevent user environment files from being sourced. OpenSSH 3.5 is now released, which includes the option PermitUserEnvironment which will prevent this attack without having to resort to restricting permissions.

Additionally, according to the sshd(8) man page from at least some releases of OpenSSH, the commands listed in the $HOME/.ssh/rc file are executed with /bin/sh instead of the user's defined shell. This appears not to be the case on systems I had available to test on, despite the man page; commands were executed using the user's configured shell (rssh), which did not allow the execution. However if it is true on your system, then a malicious user may be able to circumvent rssh by uploading a file to $HOME/.ssh/rc which will be executed by /bin/sh on that system.

If you wish to be certain that rssh will prevent your users from gaining shell access (without restricting ownerships and permissions of users' home directories, and/or compiling statically), I recommend that you upgrade to OpenSSH 3.5 now that it has become available. Be sure that sshd has the PermitUserEnvironment option set to no.