We know ld.so
searches for libraries in directories specified by the environment variable $LD_LIBRARY_PATH
, but regular users could run:
export LD_LIBRARY_PATH=dir1:dir2...
They can save infected library in a path with higher priority than the original one so that ld.so
finds that one instead of the trusted library in the ld.so.cache
.
Is this a risk?
How can we disable writing to this environment variable for regular user?
This is not a security risk at all, because you can always only set environment variables for your current environment (e.g. current Bash session) and, using the
export
command, its child environments (scripts you launch, subshells, etc.). It's impossible to escalate an environment variable created or modified into the parent environment. This includes that it's impossible for regular users to make system-wide changes, of course.So the only environment that would be affected if you run
export LD_LIBRARY_PATH=...
is your current shell and any subshells of it you might spawn later. Let's say you change the lookup path to include infected libraries at the beginning i.e. with the highest priority. Then you run an executable that loads one of the infected libs without even knowing. What happens now?You have malicious code (from the infected library) running under your own user account with regular non-admin privileges. This might sound bad, but actually... so what? It runs with regular user privileges which again means it can not affect the entire system. By the way, directly running an executable with the same malicious code would have been much easier than modifying the library lookup path and waiting for a normal executable to load it.
Conclusion: A regular user can only modify their own library lookup path, which means they can also only load those libraries themselves under their regular user account with regular non-system-wide privileges. That said, it makes no difference whether they force loading an infected library or directly run an infected executable. You would gain absolutely nothing if that environment variable could not be overridden by users.
PS: There are also executables which have the setuid or setgid flag set, which means they will not run as the user/group of the one who runs them, but of the one who owns them. For example the
sudo
executable is owned by root and has the setuid flag set, which means it always runs as root when executed. For security reasons, the$LD_LIBRARY_PATH
variable is ignored by executables with one of the setuid/setgid flags set to make sure that the regular user can not make an executable running with root privileges to load arbitrary libraries.(Thanks to @Rinzwind for pointing this out!)