4 ms·

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 or

by eridius 12y ago

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. But so what? That'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'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. 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. This also doesn'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.

geocar 12y ago
They built a DMG with a "fake" Flash Installer that doesn't verify codesigning or trigger the Gatekeeper warning.
- eridius 12y ago
  Their "fake" installer is a copy of an existing codesigned app (Instruments.app) and a directory structure that causes the app to load a library from outside its app bundle when launched. In this case, since it's loading a library outside of the app bundle, the code signature is intact. But beyond that, it seems no different than just writing an application that explicitly loads something from outside its bundle. The only benefit here is it can use someone else's codesigned app instead of having to get a certificate to codesign the app themselves. But that doesn't seem particularly meaningful. Assuming the library itself isn't codesigned, this does suggest an issue with Gatekeeper, wherein it doesn't validate all the libraries that are loaded by the application. If that's true, it seems like something that should be relatively easy for Apple to fix without affecting legitimate functionality (because any codesigned app has no need to load non-codesigned libraries). The results are also wildly overblown. The entire attack requires the user to open a downloaded DMG and run a contained app without copying the app. This is not something people do very often, and if this really is a serious threat, then a simple rule of "don't launch apps from DMGs" suffices (merely moving the app out of the DMG neuters the attack).

by eridius 12y ago

geocar 12y ago

They built a DMG with a "fake" Flash Installer that doesn't verify codesigning or trigger the Gatekeeper warning.

eridius 12y ago
Their "fake" installer is a copy of an existing codesigned app (Instruments.app) and a directory structure that causes the app to load a library from outside its app bundle when launched. In this case, since it's loading a library outside of the app bundle, the code signature is intact. But beyond that, it seems no different than just writing an application that explicitly loads something from outside its bundle. The only benefit here is it can use someone else's codesigned app instead of having to get a certificate to codesign the app themselves. But that doesn't seem particularly meaningful. Assuming the library itself isn't codesigned, this does suggest an issue with Gatekeeper, wherein it doesn't validate all the libraries that are loaded by the application. If that's true, it seems like something that should be relatively easy for Apple to fix without affecting legitimate functionality (because any codesigned app has no need to load non-codesigned libraries). The results are also wildly overblown. The entire attack requires the user to open a downloaded DMG and run a contained app without copying the app. This is not something people do very often, and if this really is a serious threat, then a simple rule of "don't launch apps from DMGs" suffices (merely moving the app out of the DMG neuters the attack).