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.

Vulnerability description

Applications may install privileged helpers using SMJobBless() API. If they use such an API, both - the main app and the helper have to set a proper SecRequirement in their Info.plist files. The privileged helper’s Info.plist has to contain a Clients allowed to add and remove tool (SMAuthorizedClients) key. 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.

If such a registered helper tries to access protected resources TCC will:

  1. Validate if the helper is properly signed
  2. Get the SMAuthorizedClients value from its embedded Info.plist
  3. Query the OS and search if there is any process meeting the requirement:
  4. Make that process responsible for the helper
  5. Verify if the responsible process has proper permissions and grant the helper access

BTW - The method responsible for determining the main process is -[TCCDAttributionChain _prettyGoodGuessForResponsibleProcessesForPrivilegedHelperProcess:]. I really love that name. 😂

Exploitation scenarios

Impersonation Apple’s Installer permissions

I abused a legitimate Apple’s macOS application – In this scenario user will be asked if they want to grant access to the non-suspicious

Impersonation Dropbox Full Disk Access permission

I abused Dropbox that usually has already the Full Disk Access permissions granted by the user. Of course, it can by any other app like Terminal or iTerm2. The malicious helper doesn’t make TCC prompt the user as the permissions are already granted.


6th August 2020Report sent to Apple
10th August 2020Apple validated the report
19th August 2020Apple asks for more details
19th August 2020I sent the additional details
20th August 2020Apple reproduces the issue
31st August 2020Apple asks for more details
31st August 2020I sent the additional details
21st September 2020Apple responds that this vulnerability will be fixed in the upcoming update
28th September 2020I confirmed that the issue is no longer reproducible on Big Sur Beta 8
12th November 2020Apple assigns CVE-2020-10008 for this vulnerability
16th February 2021Apple adjudicates this issue as eligible for the Apple Security Bounty 🎉

Apple’s fix

Now TCC verifies if the helper has been signed with the same team ID as the main application.