Introduction
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.
Overview
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:
- Validate if the helper is properly signed
- Get the SMAuthorizedClients value from its embedded
Info.plist
- Query the OS and search if there is any process meeting the requirement:
- Make that process responsible for the helper
- 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 – Installer.app. In this scenario user will be asked if they want to grant access to the non-suspicious Installer.app.
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.
Timeline
Date | Action |
---|---|
6th August 2020 | Report sent to Apple |
10th August 2020 | Apple validated the report |
19th August 2020 | Apple asks for more details |
19th August 2020 | I sent the additional details |
20th August 2020 | Apple reproduces the issue |
31st August 2020 | Apple asks for more details |
31st August 2020 | I sent the additional details |
21st September 2020 | Apple responds that this vulnerability will be fixed in the upcoming update |
28th September 2020 | I confirmed that the issue is no longer reproducible on Big Sur Beta 8 |
12th November 2020 | Apple assigns CVE-2020-10008 for this vulnerability |
16th February 2021 | Apple 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.