2020-12-29, 15:00–16:00 (Europe/Berlin), Chaos-West TV
"SomeApp would like to access files in your Documents folder." Anyone who has used macOS recently will be familiar with these prompts. But how do they work? What happens if you deny the access? Are they an effective defense against malware?
Sandboxing on macOS was introduced 13 years ago, but Apple didn't leave it at that. Starting with the release of macOS Catalina in 2019, even non-sandboxed apps need to deal with sandbox-like restrictions for files: all apps now need to ask permission to access sensitive locations, like the user's documents or desktop folder. Features such as the camera and geolocation already needed user approval from a permission prompt. This system of user controlled permissions is known as Transparency, Consent, and Control (TCC). Any new security measure like this will also mean the introduction of new security boundaries, with new classes of vulnerabilities. Many parts of the system have to be re-examined to check for these vulnerabilities. For example, apps can now try to attack other apps in order to "steal" the permissions granted by the user to those apps. Apple has taken steps to allow apps to defend themselves against this, such as the hardened runtime. Ultimately, however, it is up to the developer of an app to safeguard its permissions. Many developers are not aware of this new responsibility or do not take it seriously. Developers who are used to the security model of Windows or Linux often do not know that these boundaries even exist. To make matters worse, Apple's documentation and APIs for these features are not as clear and easy to use as they should be. This talk will start with an overview of local security restrictions that apps on macOS need to deal with. Then, it will cover some ways these protections might be bypassed in third-party applications. Finally, we will show some vulnerabilities we found in software that allowed escaping the macOS sandbox, stealing TCC permissions and privilege escalation, such as CVE-2020-10009 and CVE-2020-24428.