[shaded-enmity]

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

[shaded-enmity]

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

[rurban]

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

[BenjiWiebe]

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.

[alex_duf]

I'm curious about 2, why?

[GabrielTFS]

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.

[shaded-enmity]

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