Environmental Disaster: A LaunchServices Tale

The talk opens with a refresher on the macOS App Sandbox, which is meant to contain apps installed from the Mac App Store and limit damage from compromised apps. It explains why the ability to start other applications through Launch Services is a notable gap, since launched apps do not inherit the sandbox. The speaker traces how an open request moves from the framework to the Core Services UI agent and then to the process-launching daemons.

The core problem is that a sandboxed app can set environment variables on an unsandboxed application it launches. The speaker shows several ways this was abused: injecting a dynamic library into a scripting host, redirecting the home directory so a plugin loader reads from a path inside a sandbox container, and using a deprecated API to launch a Perl interpreter whose debug mode runs attacker-supplied code. An Electron app was also targeted through Node options. Each vector was addressed by a separate patch across several macOS releases, and the speaker argues the underlying design issue remains.

For defenders, the talk offers detection heuristics. These include flagging unsandboxed processes whose home variable points into another app's sandbox container, watching Electron apps launched with run-as-node settings, and treating a sandboxed parent that launches an unsandboxed child through Launch Services as suspicious. Developers are advised to avoid naming apps in ways that match Electron's own binary and to disable the run-as-node fuse. The speaker also released a tool for reversing recent macOS private frameworks.