Ephemera
Ephemera

Reputation: 8970

Detecting and intercepting linked library dependencies at runtime

On a UNIX system is there a simple way to identify whether a dynamic (shared) library depends on other dynamic libraries?

I'm exploring system level APIs such as dlopen and friends in C and C++. I have a controlled environment where I will be calling dlopen and mapping specific functions. The idea is that people will be able to write native plugins to the application (and let us assume for the moment that it is in the author's best interest to make sure the library actually performs the correct function and is not malicious).

However, as a security measure I would like to ensure at runtime that the loaded dynamic library does not link to any other dynamic libraries (the intention being to disallow system calls and only permit functions from the local maths library) - and if it does, don't load it.

Some (long and/or difficult) solutions I've come up with:

Is there a simple(r) way of checking dynamic libraries' dependencies?

Upvotes: 1

Views: 518

Answers (1)

Employed Russian
Employed Russian

Reputation: 213506

However, as a security measure I would like to ensure at runtime that the loaded dynamic library does not link to any other dynamic libraries

Note that a dynamic library can import a symbol without explicitly linking to any other dynamic library. For example:

int foo() { return open("/etc/passwd", O_RDONLY); }

gcc -fPIC -shared -o foo.so foo.c -nostdlib

Now foo.so does not have any DT_NEEDED shared library dependencies, yet will still open /etc/passwd at will.

(the intention being to disallow system calls and only permit functions from the local maths library) - and if it does, don't load it.

There is so much wrong with your intention, it's not even funny.

For a start, you don't need to link to any external library to execute system calls directly, it can be trivially done in assembly.

Also, the plugin can find and modify dynamic loader's data, and once it does, it can make your main program do arbitrary things. For example, it can hijack all of your main program's calls into libc.so, and redirect them elsewhere.

Once you run untrusted code in your process, it's game over.

solutions I've come up with

None of them have even remote chance of working. Any time you expend on this is time totally wasted.

Upvotes: 1

Related Questions