Lesson 5.49: Shared-library hijacking
A program rarely runs alone: the dynamic loader finds its shared libraries by searching a list of directories, and whoever can write into the first matching directory decides what code runs inside it. Build paths left in a binary's RUNPATH and writable directories in /etc/ld.so.conf.d are two classic ways in, and when the program runs as root, so does the planted library. In the lab a nightly report that root runs picks up a library from /tmp. You read the search path with readelf, see the resolution with ldd, keep the planted copy as evidence, close the hole and fix a second one in the system-wide loader configuration.
18 min
You will learn to
- Explain the dynamic loader's search order
- Read NEEDED and RUNPATH entries with readelf -d
- See which file each library resolves to with ldd
- Recognise writable directories in RUNPATH and ld.so.conf.d
- Remove the hijack and rebuild the loader cache with ldconfig
Key terms
- Dynamic loader
- ld.so: finds and loads a program's shared libraries before main() runs.
- NEEDED
- A library name the binary requires, recorded in its dynamic section.
- RUNPATH / RPATH
- Directories baked into the binary that the loader searches; RUNPATH comes after LD_LIBRARY_PATH, the older RPATH before it.
- ld.so.cache
- The loader's index of system libraries, built by ldconfig from /etc/ld.so.conf.d.
- Library hijacking
- Placing a malicious library where the loader finds it first.
← Robust shell scripts: fail safely · All lessons · Continuous compliance: scheduled scans and drift →