Full Report
In macOS, most processes run in a restricted sandbox with the com.apple.security.app-sandbox entitlement. These sandbox restrictions are applied before the app's main function via containerization via the dyld library. Files that are dropped from the app are quarantined by default. Forked processes inherit the properties. The Service Sandbox, such as Apple daemon services, manually call the sandboxing via app specific sandbox properties. In this mode, the quarantine functionality has to be manually invoked and is not done automatically. A common way for a sandbox escape in the past was targeting Mach services running the System or User domain. The PID domain seems to be accessible to all sandbox apps, giving us some more attack surface without extra entitlement checks. The Application service type is a newer XPC service. When loading an application, it appears that it is automatically registered to the XPC service when loaded. The key insight is that we have an access control issue - the sandbox applications are able to call this API with lots of permissions. To exploit this, they started finding all applications that were XPC services registered to the PID domain that were XPC Applications. SystemShoveService.xpc has powerful entitlement for com.apple.rootless.install to work around Protection (SIP). The XPC service does not check the incoming client. This allows us to drop an app folder that will not be quarantined or a DMG file to be executed. They have a separate blog post on this one. storagekitfsrunner runner only had a single function that took in an executable path and arguments. Obviously, this leads to the ability to start a process that isn't sandboxed to escape. Many of the other vulnerabilities are similar to this pattern. Call XPC from the sandbox to execute a privileged action. "Privileged" in this case is interesting though. If there is any file handling, these files will be created without quarantine, thus resulting in them being directly executable. Much of figuring out the vulnerable apps required a ton of reverse engineering to do. Another one was an app with the Full Disk Access TCC entitlement. It's purpose is to give an app complete read/write access to the file system. This is done by calling the sandbox_extension_issue_file to issue a file token under the hood. This pattern of proxying permissions from an XPC app to the underlying app is a somewhat common pattern but can suffer from a confused deputy problem. Another attack uses this to access Photos and the camera directly to bypass a TCC permission check. Several of the issues required funny symlink or folder creations to exploit properly. All in all, they ended up with 10+ vulnerabilities with 5 still in the patching queue. Once you find a new attack surface that seems unexpected, hit it hard until all of the bugs are gone! Good post on the root cause of the vulns and how they were exploited.
Analysis Summary