Re: LD_PRELOAD used with setuid programs (was Re: Fakeroot security problem)
On Mon, 9 Feb 1998, Christoph Lameter wrote:
> Nobody should be able to run LD_PRELOAD with suid binaries. The issue with
> nfslock can be solved differently as Joost has said. And being able to set
> LD_PRELOAD on one machine and then rsh to exec a command on another
> (and the other machine obeys the LD_PRELOAD!) seems to be another reason
> to disable LD_PRELOAD. That raises a lot of security issues. If
> nobody else will do it then I will upload a version that fixes the hole.
>
As the libc maintainer I would strongly advise against such a move.
I currently have two patches that fix this "problem" and could install
either of them for the next release. The reason that I haven't done so
stems from my being unconvinced at this time that it is the correct thing
to do.
Your statements above don't do much to convice me (nobody should be able
to run LD_PRELOAD programs?).
There has been a long discussion on libc-hacker about this very subject
and Ulrich seems still unconvinced (prime reason for not changing). The
crux of the discussion seems to center around the libraries in /lib and
/usr/lib. Ulrich suggests that all of these libraries should be considered
secure and that the need to run unsecure libraries should see them
installed somewhere else (/usr/local/lib was suggested). The opposing
argument seems to suggest that one of these libraries may have an
un-secured routine that can be accessed by a user using LD_PRELOAD,
yielding an exploit. I submit that if this is the case LD_PRELOAD is not
needed to exploit the hole. The lack of secure code in this routine is the
true culprit. I would suggest the "bug" is in the library not the loader.
I have a complete archive of the discussion on libc-hacker and will gladly
provide it to anyone who is interested, but very little was decided in
this discussion.
Please note that I am not refusing to consider this issue, I am only
currently unconvinced. I am a bit surprised that our Fearless Leader
hasn't spoken up on this subject. I would very much like to hear what he
has to say on the subject.
The two main objections that I have to this change have not been
addressed.
1. Changes fundamental behavior in opposition to upstream source.
2. Changes behavior to be different from other Unices.
In addition, it seems that if we defeat this "feature" the ability to
LD_PRELOAD a library for an suid binary must still be allowed for root.
This leaves me with only one question. Is there any good reason for a user
to need to LD_PRELOAD a library against an suid program? If a user doesn't
need this "feature" or should be protected from it, then I tend to lean
toward fixing the loader to disallow such.
Waiting is,
Dwarf
--
_-_-_-_-_-_- Author of "The Debian User's Guide" _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-sparc-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: