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?

  • Thanks @Byte Commander for editing. my English is not good:) – Sinoosh Jul 22 '16 at 7:55
  • No problem, it's better than the average :) – Byte Commander Jul 22 '16 at 7:56

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!)

| improve this answer | |
  • Thanks a lot ! I am reading a book it says " the LD_LIBRARY_PATH is considered to be a security risk because it might allow unauthorized programs access to system libraries accidentally or otherwise expose system library paths to unauthorized users." what the means? – Sinoosh Jul 22 '16 at 8:32
  • 1
    @Sinoosh I can't really think of a reason why it should be a security issue if an untrusted application knows the location of my system libraries. If everything is configured correctly and you have not messed with permissions, they should be owned by root and not writeable by anyone else, which means there is no risk that they get infected or modified in any way (unless you run the untrusted application as root, but you won't do this, right?) – Byte Commander Jul 22 '16 at 8:39
  • 1
    @Sinoosh see xahlee.info/UnixResource_dir/_/ldpath.html – Rinzwind Jul 22 '16 at 8:44
  • @ Byte Commander , I am agree with you not with Author:) – Sinoosh Jul 22 '16 at 8:46
  • This answer is not entirely correct. LD_LIBRARY_PATH is of course a security issue when you are loading a malicious library in the first place and change how a binary behaves. – heemayl Jul 22 '16 at 17:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.