Shared libs-SUID-Security

Robert Connolly robert at
Thu Feb 3 09:40:00 PST 2005

On February 3, 2005 12:10 pm, Randy McMurchy wrote:
> My apologies if this is off-topic for this list, however, due to the
> question being security related, I thought I could get good answers
> from you security gurus.
> Could you review the question posted at:
> and perhaps provide an answer for me?
> I'm somewhat stuck trying to update a package, and would really like
> to know if I'm making a mistake by building a shared library.

One of the major problems with using shared libraries is the LD_PRELOAD 
variable. Glibc and uClibc both do credential checks, and will disallow stuff 
like this when a program's UID and EUID are different, which is what happens 
when running suid programs. David Wheeler has written about this in the 
secure programing howto. See:

There was an exploit for sshd a few years ago where the user could set the 
environment (and LD_PRELOAD) before logging in. This is why 
PermitUserEnvironment exists in sshd_config, and is no by default.

Ulrich Drepper doesn't like static libs.. " Fixed addresses are the dreams of 
attackers." I agree with him on this. See:

Other than environment variables like ld-preload I can't think of any reason 
dynamic linking is more vulnerable than static, but libc has thought about 
this and made provisions for it. In hlfs, using the pax kernel patch, there 
are far more advantages to dynamic/shared. In your case there may be a small 
increase in the threat level with dynamic linking, which can be easily 
balanced with pax.


More information about the hlfs-dev mailing list