8 ms·

Ldd(1) and Untrusted Binaries (2023)

59 points by 3np 2y ago

blueflow 2y ago
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?
- juped 2y ago
  I'm astonished that this melted sand performs computations, but Shockley closed my CVE "not a bug"
ChoHag 2y ago
[flagged]
- anthk 2y ago
  How does LDD behave in {net,open,free}bsd?
  - ReleaseCandidat 2y ago
    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 https://docs.oracle.com/cd/E88353_01/html/E37839/ldd-1.html
    - anthk 2y ago
      Then is not a GNU issue.
- quotemstr 2y ago
  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.
- Asooka 2y ago
  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.
  - quotemstr 2y ago
    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.
  - secondcoming 2y ago
    Have you tried to address any of these issues yourself, or are you just going to wait for someone else to do it?
  - ChoHag 2y ago
    [dead]
  - anthk 2y ago
    Rust is no magic. A bug in the runtime = the whole castle rumbles down. And GNU is no Unix. You are very confused about what GNU is. Is not Linux, Linux it's a transitional kernel. Hurd, to begin width, has modular drivers able to be run in userspace and it has namespaces (a la plan9) making it potentially far more secure and not needing neither SUID or group perms to achieve mundane tasks such as mounting a volume. GNU was born to provide the ITS freedoms such as Emacs and Lisp on top of a more secure kernel based on Unix to solve random memory access violations potentially made from concurrent users running Lisp interpreters. ITS was like that, every user could capture and debug every other one's processes, even the system ones. But the 80's had a different mindset, and Unix ruled the academia and military. GNU was made to give more power to the user, it has both a microkernel design and daemons/namespaces to be able to do more stuff by themselves without misconfiguring the system. Linux was just a good enough kernel to put GNU in the 90's as Hurd wasn't (and still isn't albeit today it's a bit more usable) near complete. So, they began to promote GNU/Linux until GNU/Hurd got finished.
aleden 2y ago
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.
- ReleaseCandidat 2y ago
  It's not about calling the app itself - that doesn't happen with ldd. ldd does not know about dlopened libraries.
  - aleden 2y ago
    I guess I wasn't sure that DT_NEEDED entries covered everything. Sometimes you have stuff that happens in DT_INIT constructors.
    - ReleaseCandidat 2y ago
      Dynamic dlopen calls do not appear in the ELF at all, these are "normal" function calls.
      - sim7c00 2y ago
        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
        aleden 2y ago
        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.
        2y ago
ReleaseCandidat 2y ago
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.
- quotemstr 2y ago
  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.
  - ReleaseCandidat 2y ago
    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.
- therein 2y ago
  I wonder what happens if it specifies itself as the interpreter.
  - rep_lodsb 2y ago
    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?)
anthk 2y ago
objdump -x /path/to/binary | grep NEEDED
- ReleaseCandidat 2y ago
  It's not same, as ldd does print transitive dependencies too. libtree is comparable to ldd
  - anthk 2y ago
    True; but you can write a recursive parser with awk.
quotemstr 2y ago
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.
- ReleaseCandidat 2y ago
  > strncpy strncpy had been touted the "safe strcpy alternative" for years.
  - pjmlp 2y ago
    Which also isn't one, it only appears to be.
omoikane 2y ago
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 https://cygwin.com/cygwin-ug-net/ldd.html
- userbinator 2y ago
  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.
  - omoikane 2y ago
    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.
    - userbinator 2y ago
      Due to ASLR, those addresses wouldn't be useful either as they would change with the next process created.
      - omoikane 2y ago
        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.
  - pjmlp 2y ago
    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.
krosaen 2y ago
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.

59 points by 3np 2y ago

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?

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

ChoHag 2y ago

[flagged]

anthk 2y ago
How does LDD behave in {net,open,free}bsd?
- ReleaseCandidat 2y ago
  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 https://docs.oracle.com/cd/E88353_01/html/E37839/ldd-1.html
  - anthk 2y ago
    Then is not a GNU issue.
quotemstr 2y ago
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.
Asooka 2y ago
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.
- quotemstr 2y ago
  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.
- secondcoming 2y ago
  Have you tried to address any of these issues yourself, or are you just going to wait for someone else to do it?
- ChoHag 2y ago
  [dead]
- anthk 2y ago
  Rust is no magic. A bug in the runtime = the whole castle rumbles down. And GNU is no Unix. You are very confused about what GNU is. Is not Linux, Linux it's a transitional kernel. Hurd, to begin width, has modular drivers able to be run in userspace and it has namespaces (a la plan9) making it potentially far more secure and not needing neither SUID or group perms to achieve mundane tasks such as mounting a volume. GNU was born to provide the ITS freedoms such as Emacs and Lisp on top of a more secure kernel based on Unix to solve random memory access violations potentially made from concurrent users running Lisp interpreters. ITS was like that, every user could capture and debug every other one's processes, even the system ones. But the 80's had a different mindset, and Unix ruled the academia and military. GNU was made to give more power to the user, it has both a microkernel design and daemons/namespaces to be able to do more stuff by themselves without misconfiguring the system. Linux was just a good enough kernel to put GNU in the 90's as Hurd wasn't (and still isn't albeit today it's a bit more usable) near complete. So, they began to promote GNU/Linux until GNU/Hurd got finished.

aleden 2y ago

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.

ReleaseCandidat 2y ago
It's not about calling the app itself - that doesn't happen with ldd. ldd does not know about dlopened libraries.
- aleden 2y ago
  I guess I wasn't sure that DT_NEEDED entries covered everything. Sometimes you have stuff that happens in DT_INIT constructors.
  - ReleaseCandidat 2y ago
    Dynamic dlopen calls do not appear in the ELF at all, these are "normal" function calls.
    - sim7c00 2y ago
      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
      - aleden 2y ago
        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.
        2y ago

ReleaseCandidat 2y ago

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.

quotemstr 2y ago
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.
- ReleaseCandidat 2y ago
  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.
therein 2y ago
I wonder what happens if it specifies itself as the interpreter.
- rep_lodsb 2y ago
  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?)

anthk 2y ago

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

ReleaseCandidat 2y ago
It's not same, as ldd does print transitive dependencies too. libtree is comparable to ldd
- anthk 2y ago
  True; but you can write a recursive parser with awk.

quotemstr 2y ago

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.

ReleaseCandidat 2y ago
> strncpy strncpy had been touted the "safe strcpy alternative" for years.
- pjmlp 2y ago
  Which also isn't one, it only appears to be.

omoikane 2y ago

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 https://cygwin.com/cygwin-ug-net/ldd.html

userbinator 2y ago
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.
- omoikane 2y ago
  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.
  - userbinator 2y ago
    Due to ASLR, those addresses wouldn't be useful either as they would change with the next process created.
    - omoikane 2y ago
      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.
- pjmlp 2y ago
  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.

krosaen 2y ago

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.