hunting-dynamic-linker-hijacks

# Hunting dynamic-linker hijacks: the binary is fine, its search path is not A trusted program can be perfectly written and still run your code, because it does not choose most of the code it executes: the dynamic loader does, resolving library dependencies at startup and on demand from a search path and a set of environment variables. If any input to that resolution crosses a privilege boundary under attacker influence - a preload variable the privileged process still honors, a writable directory on its search path, a run-path relative to a location you can write - the loader maps your library into the privileged process and runs your initializer as its identity. You find it by asking, for each privileged binary, where the loader looks for code and which of those places an attacker can control. ## When to use - You are auditing a privileged binary, service, container image, or package for local escalation. - Programs run as a more privileged identity and load libraries dynamically. - The launch environment, library search path, or embedded run-path may be attacker-influenced. ## Scope check Audit loader-based escalation only on hosts, images, or binaries you own or are authorized to test, with an unprivileged account you may escalate from. If you can't name the authorization, stop. ## The loop 1. **Identify the privileged binaries and how they launch.** Inventory the programs that run as a more privileged identity - services, setuid binaries, jobs - and determine...