I don't know what the correct thing to do, but you can easily detect processes that have the LD_PRELOAD environment variable defined. This is a rare enough use case for manual inspection. Something like

``` for f in /proc/*/environ ; do sudo strings $f | >/dev/null grep LD_PRELOAD && echo $f; done ```

1. Can't the process just scrub LD_PRELOAD from its environment? Linker already done it's job at that point.

2. I'd suggest against using `strings` (let alone with sudo) on attacker controlled inputs

Turns out (1) works:

  #include <stdio.h>
  #include <stdlib.h>

  static void begin() __attribute__((constructor));

  void begin() {
    unsetenv("LD_PRELOAD");
  }

Build with:

  gcc -shared -fpie -o library.so library.c

Test:

  LD_PRELOAD=~/library.so env | grep LD_PRELOAD

Usually guarded with an #ifndef DEBUG. Disallow LD_PRELOAD in Release builds

You could look at the maps of a process instead of the environ. That would show it.

Unless the ld_preload patches the process you are using to read the maps file, and gives you a false maps file.

I'm curious about 2, why?

Some versions of `strings` might try to parse the file as an executable, which could expose one to any vulnerabilities that may be present in the library used to do so.

However, on my Fedora 36 machine at least, it doesn't do so by default and I'd have to specify the `-d` flag for it to do this.

This is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...

Just tried it, I have it happening naturally in two places:

• libinput-gestures has spawned a /usr/lib/libinput/libinput-debug-events process with LD_PRELOAD=/usr/lib/coreutils/libstdbuf.so

• Firefox has spawned many /opt/firefox-nightly/firefox-bin processes with LD_PRELOAD=libmozsandbox.so

Can't an LD_PRELOAD virus just hijack fopen/fread/etc to modify the contents of the file if its path matches the pattern you described?

Yes it can. However I would assume the surface to block all diagnostics paths would be quite large and there is always some command/syscall left unblocked to detect any rootkit. Creating 100% stealth malware is possible, but difficult.

Wouldn't this malware be able to infect each of these steps and the shell itself to filter itself out of the results?

LD_PRELOAD rootkits are super common, you’re doing it wrong if you’re using dynamically linked binaries to look for malware on Linux.

I see those defined when I use firejail + firefox.

    LD_PRELOAD=libmozsandbox.so

One of the easiest ways would be using a statically linked BusyBox. This works because statically linked binaries are unaffected by LD_PRELOAD, and BusyBox has equivalents of several of the tools that would find it if not for its hiding attempts.