Petter Adsen wrote: > OK, this is veering off-topic - apologies in advance. From what I > understand, LD_LIBRARY_PATH contains additional places to look for > libraries that aren't in ld.so.conf. Off the original topic maybe but definitely a technical discussion of something important to Debian and its users. > From ld.so(8): > > LD_LIBRARY_PATH > A colon-separated list of directories in which to search for ELF > libraries at execution-time. Similar to the PATH environment > variable. Ignored in set-user-ID and set-group-ID programs. > > But what order is this information parsed in? Does LD_LIBRARY_PATH > override ld.so.conf? Ie, could I place a modified version of a > library somewhere, point LD_LIBRARY_PATH at it, and every binary > that is linked toward the original library will run functions from > the modified one, or would I also need to remove the original > library, so that only the modified one is found? The danger would > be much clearer if it overrides, since if it doesn't you will > probably notice that the original library has been disabled. Yes. LD_LIBRARY_PATH overrides the /etc/ld.so.conf file. The /etc ld.so.conf file is for general use by every command on the system. The LD_LIBRARY_PATH environment variable is specifically for the programs that have it in the environment. Also the command line --library-path overrides the LD_LIBRARY_PATH environment variable. But calling the ld.so with --library-path is very specific and wouldn't ever be something done accidentally. Calling it explicitly is useful for wrappers needing to set up a specific environment (libraries and such) different from the native host environment. > Am I even on the right track, here? You are on track. An LD_LIBRARY_PATH variable exported in the environment would potentially affect every command run in that environment. Okay to have it set to a full path to something such as /opt/foo/lib but bad if it contained a relative path and '.' is the likely trouble spot. Having /opt/foo/lib: set would cause every command to look for preload libs in the current directory and would allow the discussed type of attack against them. > > Some of us would say it is unlikely to happen to *us* but we might all > > agree that it could happen to someone else. A potential if unlikely > > exploit. > > Yes, "it would never happen to me". Dangerous attitude when it comes to > security. But hard to get people to agree to. Much easier to get people to agree that it might happen to someone else. And if it can happen to someone else then it can happen and it should be educated against. I specifically say educated against rather than guarded against. Because there is an old saying that you can make something fool proof but you can't make it damn fool proof. And another that it is hard to make things foolproof because fools are so clever. Trying to avoid every problem by adding layers and layers of software just makes a bigger mess of things. Keeping it simple is always better. Therefore I wouldn't block against PATH and LD_LIBRARY_PATH with '.' in them. That would undoubted break other cases where it is perfectly reasonable to do things that way. Bob
Attachment:
signature.asc
Description: Digital signature