Dynamic Libraries Bypass Gatekeeper
Patrick Wardle had a talk a couple of years ago about GK issues, which can be found here: Gatekeeper Exposed He showed that during that time someone could bypass GK with loading a dylib external to the main application.
[…]
The problem is that an attacker can load a dylib through other means as well, using the deprecated
NSCreateObjectFileImageFromMemoryAPI.[…]
I found this odd behavior when I wrote about screensavers for my Beyond the good ol’ LaunchAgents series. I noticed that if I place a downloaded screensaver in its location, it will be loaded without any user prompts, which was really weird as I expected GateKeeper to shout in my face.
[…]
Shared libraries, like dylibs, frameworks, plugins, etc… will be loaded by macOS without any user prompt if they were notarized. This bypasses Gatekeeper effectively as an attacker has plenty of options to get the user to drag and drop a plugin to a certain location, or drag and drop a framework to an existing application overwriting a previous one. Once the shared library is in its place it can be loaded.
Update (2021-07-15): Csaba Fitzl:
Ok, so this only works if LV is disabled. Basically this allows you to “install” any system plugin like screensaver, colorpickers, etc… without prompting the user. This is just 1 option but you can get really creative.
This is referring to the com.apple.security.cs.disable-library-validation entitlement. Screensaver plug-ins, at least, are sandboxed, though they can access the network.
Previously:
1 Comment RSS · Twitter
"Screensaver plug-ins, at least, are sandboxed, though they can access the network."
Both _legacy_ screen savers plugins and Apple's own screen savers using Apple's private APIs?
