Thus spake Robert Watson <[EMAIL PROTECTED]>: > > I can't come up right now with an idea of how exploiting LD_LIBRARY_PATH > > could be useful with any of these, but the possibility exists. OTOH, the > > recently added priviledge elevation feature should make it possible to > > have *no* setuid programs on a system, and have the kernel elevate > > priviledges for certain syscalls, based on the policy created by > > systrace. > > LD_LIBRARY_PATH is disabled for setuid binaries -- the kernel sets the > P_ISSETUGID flag, which is exported to userspace by issetugid(), which is > in turn checked by the rtld, which will refuse to observe that > environmental variable (and a number of others) as a result. We have > plenty of dynamically linked setuid binaires in the system already, and > it's not a problem.
Setuid binaries are in pretty good shape, since LD_LIBRARY_PATH is ignored for them. But most of the other standard binaries on the system are problematic because they are trusted, but they in turn trust the value of LD_LIBRARY_PATH, which is not always a safe thing to do. For example, if an administrator disables a user's account by setting the shell to a dynamically linked /sbin/nologin, the user can override the restriction by setting an LD_LIBRARY_PATH in his ~.ssh/environment file pointing to a trojaned libc. (This attack requires that he be able to access his home directory, either before being locked out or over NFS or FTP.) You can correctly argue that setting a user's shell to /sbin/nologin is the wrong way to disable the account. Fine. Remove /sbin/nologin. I still claim that this is just one example of what can go wrong when you divide trust between libc and your standard binaries. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
