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.
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.
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
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.
objdump -x /path/to/binary | grep NEEDEDIt's not same, as ldd does print transitive dependencies too. libtree is comparable to ldd
This is par for the course for GNU.
Shit code. Arrogant developers. Shoddy documentation.
In fact actually documenting that a bad thing could happen when you use a tool normally is a higher bar than GNU's documentation normally reaches.
Nah. That's not GNU. It's just the industry. Proprietary stuff can be even worse. Remember how Windows conhost has a crappy rectangle text selection model for literally two decades until Microsoft overcame their stubbornness and fixed it? Being a stick in the mud isn't a feature of GNU in particular. It's an element of human nature.
How does LDD behave in {net,open,free}bsd?
Don't know, but on Solaris it's the samé, see section "Security" https://docs.oracle.com/cd/E88353_01/html/E37839/ldd-1.html
You are getting downvoted, but you're absolutely correct. This is the usual disposition of Unix devs in general I've found. People forever stuck in the mentality that the computer is a personal toy, only for running your code and OS code, who refuse to grow up and accept responsibility for maintaining software useful in the real world. When you point it out they just act like piss-babies, cry and shout until they get their way. We put up with using code that is, as their license reminds us, "without [...] FITNESS FOR A PARTICULAR PURPOSE", simply because the amount of basic operating system services we'd have to rewrite to get rid of them is an extremely daunting task. Hopefully the Rust project can spur some development into replacing GNU and other similar shit, so we can be rid of the drooling retards for good.
Rust is a young ecosystem. Give it time. It'll ossify too, just like every other previous software ecosystem. We make progress only through continual cycles of replacement and renewal, usually by fresh eyes and fresh hands each cycle. It's always been this way and always will be. One day, Rust will be the difficult to replace ancestral crud.
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"