Ldd(1) and Untrusted Binaries (2023) | Hacker News Reader

Ldd(1) and Untrusted Binaries (2023)

jmmv.dev

59 points3np36 comments

Coincidentally, `ldd` has the same caveat on Cygwin, although there it's implemented as an executable instead of a shell script:

    ldd invokes the Windows loader on the file specified, then uses the Windows debugging interface to report DLLs loaded, and (for executables) to attempt to stop execution before the entrypoint. Thus, you should never use ldd on an untrusted file.

https://cygwin.com/cygwin-ug-net/ldd.html

I wonder why they implemented it that way, since dynamic linking on Windows is much less of a mess than on *nix systems. dumpbin /imports and Depends have been the standard there for a long time.

Maybe it's to get the addresses where the DLLs would be loaded? I think that information is not available until the process is created due to ASLR.

Due to ASLR, those addresses wouldn't be useful either as they would change with the next process created.

Well, the addresses won't be constant, but maybe some people find those addresses to be useful for something, e.g. they want to check if ASLR is enabled.

I just tried this and I get different addresses every time I ran `ldd /bin/true` on Linux, but I always get back the same addresses on Windows.

Note that Aix is a UNIX that shares the Windows dynamic libraries model.

ELF like libraries are supported, but not the way most things are expected to work, with XCOFF and export description files.

Symbian was another OS with similar model, but it wasn't a UNIX anyway, and PIPS was a compatible layer on top.

Each Elf executable can have its own "interpreter" (loader, which as default is `ld-linux. so`), so without calling the configured interpreter ldd can't know about the dependencies of such "special" executables. And the configured interpreter can be any program, AFAIK there are no limititations in the ELF format.

Yes, but in the vast majority of cases the interpreter is ld-linux.so (or the Buonic/Musl equivalent) and a safe binary inspection tool can know for sure what that interpreter will do. It's okay for that tool to say "I don't know" 0.0001% of the time.

It wasn't meant as an argument against not loading the interpreter, but an explanation why it is "normal" - but if course insecure - behavior for ldd to execute the configured interpreter.

I wonder what happens if it specifies itself as the interpreter.

Tried it, seems to crash immediately:

    $ strace ./true
    execve("./true", ["./true"], 0x7ffc9993be20 /* 40 vars */) = 0
    --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
    +++ killed by SIGSEGV +++

(hexedited copy of /bin/true; something different might happen with a specially crafted file which has no other data in it besides the name of the interpreter?)

I have found libtree to be nicer, sounds like it doesn’t suffer the same risk. But there is the added inconvenience of installing it - but usually mild given prebuilt binaries for common distributions.

ldd's shortcomings have been well known for years, but here we are. Same with strncpy. It's remarkable how sticky some tools are in people's muscle memory and how hard it is to eradicate these bad tools even when drop in alternatives are within reach. Habit is powerful.

> strncpy

strncpy had been touted the "safe strcpy alternative" for years.

Which also isn't one, it only appears to be.

Disentangling who loads what without actually running the app, i.e. allowing a sequence of dlopen() calls to succeed, seems impossible to accomplish in the presence of binary code which cannot be effectively scrutinized.

It's not about calling the app itself - that doesn't happen with ldd. ldd does not know about dlopened libraries.

I guess I wasn't sure that DT_NEEDED entries covered everything. Sometimes you have stuff that happens in DT_INIT constructors.

Dynamic dlopen calls do not appear in the ELF at all, these are "normal" function calls.

correct. you cam call dlopen anywhere so loading it into memory or even executing all easy to reach paths wont guarantee you'd get that. you might do full symbolic execution but your 'ldd' might take days or weeks :'D

My model for LDD in my head was, "run the app up until the entry point of the executable, print the loaded DSOs, and exit() before ever starting the exe." That'd get you potentially more libraries than if you just statically examine the needed libraries recursively.

I think in this case, you might be able to resolve the ones in DT_NEEDED on the disk, and parse those elf headers, and do that until they don't have any DT_NEEDED in there anymore which you didn't touch.

The reason it doesn't find all with a simple elf-parse is that included libs might depend on other libs. I'd say if your linker can figure out before executing anything after the entry-point what to resolve, it has read it from ELF files it has seen by parsing the initial executable.

I was really surprised honestly to see LDD executes stuff, but I suppose it's a very old thing, from before 'untrusted' executables were really a (big) thing.

              objdump -x /path/to/binary | grep NEEDED

It's not same, as ldd does print transitive dependencies too. libtree is comparable to ldd

True; but you can write a recursive parser with awk.

Why do people a) have these preconceptions, b) have them be accurate enough to work at all, and c) get away with shouting "but POLA" when they don't work out?

I'm astonished that this melted sand performs computations, but Shockley closed my CVE "not a bug"

Reply on news.ycombinator.com