-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At some point hitherto, ari hath spake thusly:
> I assume you are familiar with my post, entitled "ssh environment -
> circumvention of restricted shells"?

No, I'm not.  Sounds like interesting reading though.  I'm guessing
you mean a post on Bugtraq?  Feel free to provide a link or forward a
copy to me...

> It is my firm opinion that while the PATH environment variable should
> probably be the responsibility of the program used as the login shell,
> variables such as LD_LIBRARY_PATH and LD_PRELOAD are solely the daemon's
> responsibility --- no less than the UseLogin issue was, and no less than
> the similar telnet issue was back in '95 --- just because those enabled
> root access does not mean they should be solved differently when they
> stem from the same problem.  The openssh developers are apparently of a
> different mind.

I'm not entirely familiar with the topic, but from what you say above,
I'd have to say I agree with you.  It sounds like you're saying that a
user could set LD_LIBRARY_PATH or LD_PRELOAD and cause the execution
of some binary (i.e. the restricted shell) to be altered by linking
with a library under the user's control... yes?  I hadn't considered
that.

This is really a bit beyond my level of expertise... I'm admittedly no
more than vaguely familiar with the magic that happens when a program
is loaded and shared libraries are linked in, and probably less
familiar with how the user's environment can affect this process.

But if I understand what you're saying, it would seem that the user's
environment could set one of these variables, and actually affect the
execution of such a restricted shell itself such that it runs code of
the user's design.  That sucks.  If I understand the problem though, I
think this could be worked around by compiling the restricted shell
statically, and then having it clear the environment before it
executes the user's command.  Would you agree that this would solve
this particular problem, for the restricted shell?  Again, this is not
an area where I have a lot of knowledge (unfortunately).
Additionally, the restrictions on the user's home directory that I
posted in part 1 of the Solution section of the advisory would also
seem to take care of this problem, by eliminating the ability of
restricted users to affect their environment.  Do you agree with this
also?

It certainly would be better and easier for the developers of such a
shell if the OpenSSH developers would provide a way to ignore the
user's environment completely.  Again, I'm surprised they have not
done so.  Perhaps they do not realize the demand for system
administrators to be able to provide this functionality?  I would
offer to work on providing this functionality in OpenSSH, but when I
posted to the developer's list concerning the availability of rssh and
contributing it to the OpenSSH project, I only received a response
from one person, who AFAIK is not an OpenSSH developer (though I
originally thought he was).  Perhaps the OpenSSH team has no interest
in providing this sort of functionality (this is how I have taken
their lack of response).  That would be unfortunate for the many
people who use OpenSSH and desire such functionality.  I've had a few
ideas for extending rssh and improving security, but at this time it
seems rather pointless.

If I have failed to grasp the actual problem, then I would definitely
appreciate a pointer to a reference which will aid in understanding
the problem.  I'll also want to post a warning to potential users
which discusses the problem as intelligently as possible.  In some
environments, the sysadmins may not really care about this problem,
figuring that rssh is "good enough" security as is.  But they should
at least be able to decide based on factual information...

Thanks.

- -- 
Derek Martin               ddm@pizzashack.org    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Ywu5djdlQoHP510RArA6AJ4gvXxAKTdGQUULbSXVWx5HklvAnACgq/JK
a/W+Ys5d49yxREk7U8D7eGk=
=ssHV
-----END PGP SIGNATURE-----

