3 ms·
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
by shaded-enmity 4y ago
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
- alex_duf 4y agoI'm curious about 2, why?
- shaded-enmity 4y agoThis is a nice summary: https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on...
- GabrielTFS 4y agoSome 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 4y agoTurns 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 4y agoUsually guarded with an #ifndef DEBUG. Disallow LD_PRELOAD in Release builds
- BenjiWiebe 4y agoYou 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.