ERROR: ld.so: object '/usr/local/lib' from LD_PRELOAD cannot be preloaded: ignored.

[vergotle0]

Hi

Newbie here.

After following the steps within the guide on a Centos 64-bit system I am getting the error in the heading. May I kindly ask to be pointed in the right direction to resolve the error message?

[gianlucaborello]

Hi

Are you still having issues? If yes, and you post the exact steps for me to reproduce (with a Docker container ideally) I might be able to take a look.

And sorry for the delay.

[artikrh]

Perhaps I could add more information related to this issue. I am using libprocesshider in a 64-bit system, and after following the tutorial, everything works as expected. However, there seems to be an issue when executing 32-bit ELF binaries after loading libprocesshider.so with the global dynamic linker.

For example, I have the following binary:
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=0c1a9279b30f8009b89849b540c223f2959789cc, with debug_info, not stripped

When I execute it, the binary works as intended but it also gives this 'warning' at the beginning:
ERROR: ld.so: object '/usr/local/lib/libprocesshider.so' from /etc/ld.so.preload cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.

By the way, this is not binary specific but it is true for all 32-bit programs. You can reproduce this by creating a simple C program which you can compile using gcc's -m32 flag.

While this is not a critical issue as everything still works as expected, I would like to know if there is a workaround for this issue.

[gianlucaborello]

Admittedly I never tried using a 32 bit binary, this project was more of a proof of concept I needed to publish a blog post a long time ago. I suppose in your case the 32 bit binary is using the 32 bit libc version, and the preload doesn't work.

Have you tried compiling the library itself (libprocesshider) with -m32? If it works, then you're lucky, otherwise you need that (-m32) AND patching the library to intercept the right symbol. ltrace/gdb should show you what gets called, and it should be fairly easy to fix.

After you make it work, you need to install both versions of the library (32 bit and 64 bit) in your system, so that the dynamic loader can find and load the proper one at runtime (see https://stackoverflow.com/questions/36849507/using-ld-preload-mixed-64bit-32bit-environment-in-linux).

[artikrh]

Finally fixed the problem using the $LIB environment variable which expands to lib32 directory for 32-bit programs and lib/x86_64-linux-gnu for 64-bit programs (as /usr/$LIB/libprocesshider.so in /etc/ld.so.preload) - as shown in strace. This is for Debian based systems, as for other systems it will expand to lib64 and lib (could always confirm with strace, more specifically the openat() system call).

So the solution would be to compile libprocesshider.c with both -m32 and -m64 and put the relevant architecture files to their respective referenced folders from $LIB.

In summary:

$ mkdir {32,64}
$ gcc -Wall -m32 -fPIC -shared -o 32/libprocesshider.so processhider.c -ldl
$ gcc -Wall -fPIC -shared -o 64/libprocesshider.so processhider.c -ldl
$ sudo mv 32/libprocesshider.so /usr/lib32/libprocesshider.so
$ sudo mv 64/libprocesshider.so /usr/lib/x86_64-linux-gnu/libprocesshider.so
$ sudo echo '/usr/$LIB/libprocesshider.so' > /etc/ld.so.preload