Radare2: r2 crashes when run in folder which has libc files

[b10s]

$ ls
foo  ld.so  libc.so.6  libpthread.so.0

$ r2 -d /bin/ls
*** stack smashing detected ***: terminated
Aborted (core dumped)

$ cd ..
$ r2 -d /bin/ls
Process with PID 27461 started...
.. (runs ok)

I'm on Ubuntu 18.04.5 where system libc6 is 2.27-3ubuntu1.2
Files in tmp folder are from libc6 2.32

[ret2libc]

I think you have wrongly set LD_LIBRARY_PATH to load libs from current directory. Could you show its value?

[b10s]

@ret2libc there is no LD_LIBRARY_PATH:

$ env | grep -i ld_s

However I'm not able to reproduce it on VM in some cloud with the same distro and system libc.
Probably there is something else. Interesting what it might be, why it crashes only in case my current working directory has such files

[ret2libc]

@b10s Please make sure you checked the correct env var, because there was a typo in the command you pasted (ld_s instead of ld_l). Also, print all the files in /etc/ld.so.conf.d and /etc/ld.so.conf .

[b10s]

@ret2libc sorry for typo in message, the env is clear, crash persists even after reboot. I did check env by $ env | grep -i ld_ and also inspected it by eyes.

Files are:

$ ls /etc/ld.so.conf.d
fakeroot-x86_64-linux-gnu.conf  libc.conf  x86_64-linux-gnu.conf

Config is:

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

As far as I remember I never changed them

[ret2libc]

Sorry, by "print all the files in /etc/ld.so.conf.d" i meant their content, not just their names :D

I believe this is a ld-related issue, as it already happened to other users in the past. Not sure if it helps, but also try to run sudo ldconfig.

[b10s]

$ cat /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf 
/usr/lib/x86_64-linux-gnu/libfakeroot

$ cat /etc/ld.so.conf.d/libc.conf 
# libc default configuration
/usr/local/lib



md5-8395f44bbba232d419a43a5b2f99b42a



$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf 
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

I can run r2 out of such directory, so no need to fix it, it's not a blocker for me.
Rather would like to understand why it crashes only being run from such directory

[ret2libc]

Sorry for the many questions, I'm just trying to understand :) (especially because there was already a similar report some time ago). Could you also run ldd $(which radare2)?

[b10s]

Thank you for asking : )
Yes, sure:

$ ldd $(which radare2)
    not a dynamic executable

[ret2libc]

What is radare2 then? file $(which radare2). How did you install radare2?

[b10s]

$ file $(which radare2)
/home/b10s/bin/radare2: POSIX shell script, ASCII text executable

I did install it via either sys/user.sh or sys/install.sh from sources.
Current version is:

$ r2 -v
radare2 4.6.0-git 25219 @ linux-x86-64 git.4.4.0-881-g486b7bee7
commit: 486b7bee72400fba627c849dda41fc59dfddcb75 build: 2020-11-01__03:44:12

[ret2libc]

Ok, you used sys/user.sh, that's probably the root of the problem. By installing it that way radare2 uses env.sh, which sets LD_LIBRARY_PATH=$pfx/lib:$LD_LIBRARY_PATH, however if $LD_LIBRARY_PATH is empty this results in LD_LIBRARY_PATH=ssss/lib: that I think makes it load stuff from the current working directory as well.

cc @trufae

[b10s]

@ret2libc does it mean there is possibility of DLL Share Object Hijacking ? (I don't know why it might be needed though)

[trufae]

Yep this is the problem @ret2libc i will fix it!

[karliss]

Note that if r2 is compiled and installed using meson with "-Dlocal=true" option r2 executables and libraries are linked correctly so that there is no need to use shell script which sets up environment variables and the executables can be run directly.

[trufae]

Whats this local thing doing? Setting up the rpath? The reason why sys/user does that is because rpath doesnt allow the user to move the files anywhere else and keep them working and its an antipattern many distros like gentoo and debian dislike

[ret2libc]

The moment you are using sys/user or meson+local+prefix you are compiling stuff yourself in your home directory, so distros are completely out of scope. Distros don't want their packages to be compiled with rpath, but they don't care if you use it while compiling your own things. With regards to moving files, again I don't think that's the purpose of local or sys/user. Rather they just try to provide r2 without installing them on the system and they do not try to make
it "portable" (btw i think as long as you also move the libs directory you should be able to move the binaries)