
Mach-O linking and loading tricks - ingve
http://blog.darlinghq.org/2018/07/mach-o-linking-and-loading-tricks.html
======
saagarjha
This post is great. Kudos to the author for writing this up; it helped me
learn about some things I knew the dynamic linker had some way of doing but I
didn't have name for. One question:

> In contrast, on Darwin, the (somewhat) complete path to the library
> installation, known as that library's install name, is used. This has
> presumably been done that way in order to prevent dylib hijacking, an attack
> where a malicious dylib gets placed in the library search path before the
> real one, which allows the malicious dylib to execute arbitrary code on the
> behalf of the executable that got tricked into loading it.

Couldn't you just get around this by running the application in a fake root?

~~~
lloeki
I don't think _install_name_ has for purpose to prevent dylib hijacking. In
fact there were _DYLD_LIBRARY_PATH_ , _DYLD_FALLBACK_LIBRARY_PATH_ , and other
stuff that used to trivially† go around that (now disabled — IIRC — when SIP
is active). The purpose of _install_name_ and _@executable_path_ is, to me, to
leverage the concept of a bundle (may it be a .app or a .framework) to solve
dependency hell issues and have self-contained, relocatable, forward- and
backward-compatible software.

†
[https://stackoverflow.com/a/41072072/368409](https://stackoverflow.com/a/41072072/368409)

------
ndesaulniers
I never could figure out how to work around the multilevel namespaces to
implement something like LD_PREDLOAD without recompiling with namespaces
turned off. Wish I had this article then.

