Dylib hijacking on OS X

This is a very long-winded way of saying that libraries that are loaded via @rpath are vulnerable to having a malicious library inserted earlier in the rpath order than the actual library it wants to load.<p>But so what? That&#x27;s not at all interesting. The given examples involve inserting the library into the application bundle (because the examples of @rpath-dependent loads are for frameworks embedded within the application). This is trivially detectable for any codesigned application (as the inserted library won&#x27;t be part of the code signature), and for non-codesigned apps it should be just as easy to detect this at it would be to detect an attacker that simply swaps out the expected library with a new one.<p>Performing this sort of attack also likely requires administrator privileges, and an attacker that can get administrator privileges can perform all sorts of mischief on the system.<p>This also doesn&#x27;t subvert the app store sandbox in any way, because malicious code injected into an application is still subject to the same sandbox restrictions that the application is normally subject to.

As far as I can tell, this is not a particularly interesting finding.<p>Basically, if an application tries to load a library and it isn&#x27;t there, you can create the library and it will load it.<p>On Windows, this may be a vulnerability because the program will look in the application directory and current directory for the library, which may not be secured locations.<p>On Linux, and I believe OSX too, the program will only look in system-specified locations (&#x2F;lib, &#x2F;usr&#x2F;lib, etc) which should be secured at the same or higher level than the applications themselves. If you have access there, you can just overwrite the executable.<p><a href="http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx" rel="nofollow">http:&#x2F;&#x2F;blogs.msdn.com&#x2F;b&#x2F;oldnewthing&#x2F;archive&#x2F;2006&#x2F;05&#x2F;08&#x2F;59235...</a><p>The paper points out that security software may inspect the binary or its signature. However, such security software must also inspect the libraries; otherwise, one could simply modify a library (e.g. libc) to accomplish the same task with less effort. If the security software is going to inspect the libraries anyways, it can check whether any unauthorized libraries are being loaded.

Note that you were always able to easily inject&#x2F;specify which DYLIBS were loaded into the invocation of an executable. However, the OP describes a way of doing this that is difficult (impossible in a general sense?) to detect.<p>Second, this would probably be the most effective attack against the sandbox of the Mac Store. It effectively allows injection of arbitrary code into an arbitrary child process.<p>Third, to my understanding, this does not allow user-bound privilege escalation (e.g. no root) because those are bound by the process, inside of which the code is loaded and run.<p>Honestly, though, shouldn&#x27;t be too difficult to patch.