Bypass TCC via Privileged Helpers
This vulnerability has been disclosed on @Hack in Saudi Arabia in 20+ Ways To Bypass Your Macos Privacy Mechanisms presentation. In the end, it allowed impersonating TCC entitlements of any application installed on the device.
[…]
Applications may install privileged helpers in the
/Library/PrivilegedHelpers
directory. When such a helper tries to access the protected resource (e.g. Address Book), TCC tries to determine which app is responsible for the helper. If the main app is determined, TCC checks whether the app has proper permissions and grants the helper access to the protected resources. The problem is that a malicious helper may trick TCC to select the wrong application as the main app and thus use its entitlements.[…]
It’s important to understand that the SMJobBless API is not required to register a privileged helper. A malicious application can just create a plist in the
/Library/LaunchDaemons
directory, place the helper in the/Library/PrivilegedHelpers
, load&start the helper via launchctl. So, there is no guarantee that the SMAuthorizedClients key will be pointing to the right owner.
Previously:
2 Comments RSS · Twitter
According to the timeline on Wojciech Reguła's blog it took Apple half a year to fix the bug. There is only one word for this: embarrassing. And the guy didn't even say if he actually got any money.
My read is the fix took about eight weeks. What took half a year was the bounty.
Perhaps a bit more troubling is that the engineer who named the method "_prettyGoodGuessForResponsibleProcessesForPrivilegedHelperProcess" must have already known that there was a potential issue, although perhaps they didn't foresee the security implications at the time.