|
|
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
Summary
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.
Details
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.
|
