[6090] in bugtraq
Re: Another ld-linux.so problem
daemon@ATHENA.MIT.EDU (Solar Designer)
Sat Feb 7 15:46:57 1998
Date: Sat, 7 Feb 1998 22:39:40 -0300
Reply-To: Solar Designer <solar@FALSE.COM>
From: Solar Designer <solar@FALSE.COM>
X-To: joost witteveen <joost@rulcmc.leidenuniv.nl>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <m0y197p-000CLqC@rulcmc.leidenuniv.nl> from "joost witteveen" at
Feb 7, 98 01:12:49 pm
Hello,
> It's much simpler than that:
>
> $ LD_PRELOAD=libdoesntexist /bin/su
> /bin/su: error in loading shared libraries
> libdoesntexist: cannot open shared object file: No such file or directory
> libraries that are installed on the system should be well written,
> and it should be safe for them to be specified in LD_PRELOAD.
>
> I am quite surprised by this attitude, and I think I've thought of 3
> situations where this behaviour of the dynamic linkers may _possibly_
> create security problems.
Is there a reason for this limited LD_PRELOAD support for setuid binaries,
does something depend on it? It looks like this was done intentionally...
Anyway, here's a patch for ld-linux.so 1.9.5 that I just did:
--- boot1.c.orig Mon Jul 21 16:45:35 1997
+++ boot1.c Sat Feb 7 20:17:44 1998
@@ -525,7 +525,7 @@
else
{
_dl_secure = 1;
- _dl_preload = _dl_getenv("LD_PRELOAD", envp);
+ _dl_unsetenv("LD_PRELOAD", envp);
_dl_unsetenv("LD_AOUT_PRELOAD", envp);
_dl_unsetenv("LD_LIBRARY_PATH", envp);
_dl_unsetenv("LD_AOUT_LIBRARY_PATH", envp);
(This is only to fix the LD_PRELOAD problem, not the load-old-version one.)
Signed,
Solar Designer
