Automatically detect proper libC

[savchenko]

Feature-request, not a bug.

Compiling from 27beefd, it seems like the application is failing to automatically process pretty much any ELF I supply it with.

$ bsc /bin/bash
15:00:17 [ERROR] /bin/bash: Dependent C runtime library is not recognized.

$ bsc -l /lib/x86_64-linux-gnu/libc.so.6 /bin/bash
/bin/bash: +ASLR +STACK-PROT +READ-ONLY-RELOC !IMMEDIATE-BIND ~FORTIFY-SOURCE(+memmove,+strcpy,+strncpy,+sprintf,+fprintf,+asprintf,+snprintf,+memcpy,+vfprintf,+fdelt,+printf,+longjmp,+vsnprintf,!fgets,!mbstowcs,!readlink,!memmove,!strcpy,!wcsrtombs,!wcrtomb,!strcat,!mbsnrtowcs,!mbsrtowcs,!memcpy,!getgroups,!confstr,!wctomb,!strncpy,!memset,!getcwd,!read,!stpcpy,!gethostname)

System:

# Debian 11

$ uname -vr
5.14.0-0.bpo.2-amd64 #1 SMP Debian 5.14.9-2~bpo11+1 (2021-10-10)

$ rustc -V
rustc 1.56.1 (59eed8a2a 2021-11-01)

[koutheir]

An ELF file only specifies the C library file name, not its full path.

Identifying the exact C library file for a particular ELF file without running it is a fairly complex issue, because that identification depends on the behavior of the dynamic loader. Debian takes advantage of this situation to implement its multi-arch feature, where multiple C libraries for different architectures can be installed on the system, and selecting which one is actually loaded for a particular executable can go through a complex process.

The ldd binary runs the dynamic loader algorithm to figure out which libraries would be used by an executable without running it. ldd is provided as part of the dynamic loader system. ldd does not work for executables that cannot run on the system (e.g., cross-compiled binaries). This project does not want to depend on the presence or the output of ldd.

Running an executable in order to figure out what C library it actually loads is, by design, not an acceptable solution for this project.

If you can think of an approach that could be used to solve this issue, then please share it, and it might end up making this project better for everyone. Keep in mind that this project DOES NOT trust input binaries.

[savchenko]

This might be entirely irrelevant, but...

$ relro=$(readelf -l /bin/bash | grep -i relro -q; echo $?)

...and so on.

[koutheir]

I don't understand what you're trying to say. Can you elaborate?

[savchenko]

I was replying to...

If you can think of an approach that could be used to solve this issue

The snippet above is a crude parsing of readelf output in an attempt to determine if binary has RELRO.

Perhaps it can be used in the similar manner to check the .gnu.version_r and derive guesstimate the libC from it.

[koutheir]

The snippet above is a crude parsing of readelf output in an attempt to determine if binary has RELRO.

RELRO is specified completely in the ELF file, and it has nothing to do with which C library is used to run the executable.

Perhaps it can be used in the similar manner to check the .gnu.version_r...

The GNU version specifies symbol versions, so the linker can resolve multiple symbols with the same name implementing different versions of the same API. It has nothing to do with the C library file. It does not indicate even the version of the C library, only a lower limit.

and derive guesstimate the libC from it.

I don't know how to go from a minimum version of the C library, to a file path.

[koutheir]

Version 1.3.0 now tries to detect the full path of the C library by reading the dynamic loader cache.