5 ms·

If I'm not mistaken putting DLLs in the same directory as the executable lets you do the same on Windows. Mods and cracks for videogames usually plant a fake Di

If I'm not mistaken putting DLLs in the same directory as the executable lets you do the same on Windows. Mods and cracks for videogames usually plant a fake DirectX dll in the game folder.

tomyws 9y ago
Absolutely correct. Although this was intentional behaviour, it was given a security advisory[1]. In practice it allowed all sorts of exploits, including dumping packed executables for cracking, as you say. [1]: https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2010/2269637 https://docs.microsoft.com/en-us/security-updates/SecurityAd...
- iancarroll 9y ago
  Though to be clear, this is like one of a billion ways to inject code into processes on Windows.
AnIdiotOnTheNet 9y ago
Yeah, but UNIX developers love namespace conflicts and hardcoded paths, so something as simple as "look for libs in the directory your binary is in" either never occurred to them or was rejected under various arbitrary concerns.
- DavidBuchanan 9y ago
  I wouldn't categorise security as an "arbitrary concern".
  - AnIdiotOnTheNet 9y ago
    In order to exploit this you need to be able to write to the directory where the binary is. "Security" is trotted out as an arbitrary concern quite often because a lot of security people don't have any concept of risk analysis or cost/benefit. If it was up to them no one would ever do anything because that way they can't make a mistake.
- sigjuice 9y ago
  This is possible on Linux using gcc -Wl,-rpath,'$ORIGIN/../lib' See http://man7.org/linux/man-pages/man8/ld.so.8.html http://man7.org/linux/man-pages/man8/ld.so.8.html
  - jwilk 9y ago
    This should work also on other ELF-based systems.
- theamk 9y ago
  Huh? It has not been rejected -- it is up to compiler/linker what to put in RPATH, and you can totally set RPATH to $ORIGIN. There is a nice tool, chrpath, to do so. For example, java sets it to: /usr/bin/java: RPATH=$ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64 I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved.
  - AnIdiotOnTheNet 9y ago
    > I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved. I other words, nobody uses it. So many conflicts could be easily solved if applications dropped this retarded insistence on spreading files over the hierarchy by type, but they just keep doing it because they mistake tradition for wisdom.

If I'm not mistaken putting DLLs in the same directory as the executable lets you do the same on Windows. Mods and cracks for videogames usually plant a fake DirectX dll in the game folder.

tomyws 9y ago

Absolutely correct. Although this was intentional behaviour, it was given a security advisory[1]. In practice it allowed all sorts of exploits, including dumping packed executables for cracking, as you say. [1]: https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2010/2269637 https://docs.microsoft.com/en-us/security-updates/SecurityAd...

iancarroll 9y ago
Though to be clear, this is like one of a billion ways to inject code into processes on Windows.

AnIdiotOnTheNet 9y ago

Yeah, but UNIX developers love namespace conflicts and hardcoded paths, so something as simple as "look for libs in the directory your binary is in" either never occurred to them or was rejected under various arbitrary concerns.

DavidBuchanan 9y ago
I wouldn't categorise security as an "arbitrary concern".
- AnIdiotOnTheNet 9y ago
  In order to exploit this you need to be able to write to the directory where the binary is. "Security" is trotted out as an arbitrary concern quite often because a lot of security people don't have any concept of risk analysis or cost/benefit. If it was up to them no one would ever do anything because that way they can't make a mistake.
sigjuice 9y ago
This is possible on Linux using gcc -Wl,-rpath,'$ORIGIN/../lib' See http://man7.org/linux/man-pages/man8/ld.so.8.html http://man7.org/linux/man-pages/man8/ld.so.8.html
- jwilk 9y ago
  This should work also on other ELF-based systems.
theamk 9y ago
Huh? It has not been rejected -- it is up to compiler/linker what to put in RPATH, and you can totally set RPATH to $ORIGIN. There is a nice tool, chrpath, to do so. For example, java sets it to: /usr/bin/java: RPATH=$ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64 I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved.
- AnIdiotOnTheNet 9y ago
  > I believe the reason it does not happen by default is that binaries go to /usr/bin, and no .so files should appear there. Also it breaks when hardlinks are involved. I other words, nobody uses it. So many conflicts could be easily solved if applications dropped this retarded insistence on spreading files over the hierarchy by type, but they just keep doing it because they mistake tradition for wisdom.