3 ms·

Yeah, I'm real glad that the Unix permission scheme is actually worthless because of non user intended code execution in core utilities.

ajross 17y ago
I'm not sure that snark is warranted. This is a development tool. You use ldd when you're curious what libraries a binary links against; more or less by definition that's because you're planning to run said binary at some point in the future. The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries. But that's protected by the default link paths already. So you'd first have to fool them into setting their LD_LIBRARY_PATH properly, and then get the bad binary on the system. So how is this easier than just fooling them into opening a shell for you?
- viraptor 17y ago
  > The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries. Not quite. You fool someone into checking what libraries is your file linked against, which most people would assume - is a safe operation (just reading some info, right?) It doesn't need any lookup path modification, because rpath can be compiled into the binary itself. Basically you can prepare anything you need in your home directory. The only part that someone else has to do is to run `ldd your_file`. It's not only a development tool. It's also a sysadmin and packaging tool. Some parts of .deb and .rpm automation depend on that ldd (you don't have to use that, but it's nice when the dependencies are found automatically)
  - ajross 17y ago
    I think we agree on the facts, just not the interpretation. Once more, it requires getting an untrusted binary into the target user's environment such that they can be fooled into running it. How is that different from any of the four million other ways of fooling users into running untrusted binaries?
    - DougBTX 17y ago
      Clearly the difference is in the subtly. The arbitrary code being run is in the loader, not the body of the executable, allowing it to be run without an explicit, "go to the shell and run my binary," step. This will be a new attack vector to many people.

ajross 17y ago

I'm not sure that snark is warranted. This is a development tool. You use ldd when you're curious what libraries a binary links against; more or less by definition that's because you're planning to run said binary at some point in the future. The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries. But that's protected by the default link paths already. So you'd first have to fool them into setting their LD_LIBRARY_PATH properly, and then get the bad binary on the system. So how is this easier than just fooling them into opening a shell for you?

viraptor 17y ago
> The only path to a security vulnerability here is to fool the user into linking against untrusted binaries and libraries. Not quite. You fool someone into checking what libraries is your file linked against, which most people would assume - is a safe operation (just reading some info, right?) It doesn't need any lookup path modification, because rpath can be compiled into the binary itself. Basically you can prepare anything you need in your home directory. The only part that someone else has to do is to run `ldd your_file`. It's not only a development tool. It's also a sysadmin and packaging tool. Some parts of .deb and .rpm automation depend on that ldd (you don't have to use that, but it's nice when the dependencies are found automatically)
- ajross 17y ago
  I think we agree on the facts, just not the interpretation. Once more, it requires getting an untrusted binary into the target user's environment such that they can be fooled into running it. How is that different from any of the four million other ways of fooling users into running untrusted binaries?
  - DougBTX 17y ago
    Clearly the difference is in the subtly. The arbitrary code being run is in the loader, not the body of the executable, allowing it to be run without an explicit, "go to the shell and run my binary," step. This will be a new attack vector to many people.