Broken isolation: Draining your Credentials from Popular macOS Password Managers

The talk opens with the process isolation model on macOS. Applications running under the same user ID should not be able to control each other, and injecting into another process normally depends on entitlements, System Integrity Protection and the hardened runtime. The speaker explains why this boundary matters, since injecting into an entitled app could bypass privacy controls, and notes that hardened runtime exceptions are often switched on by developers.

The middle of the talk tests several password managers chosen for different languages and distribution channels. A native Objective-C client that disables library validation could load a malicious plugin from a user-writable Application Support folder. A Mac App Store build of an Electron-based manager ran without the hardened runtime, so dynamic library injection worked and a simple keylogger captured the master password. An Electron app with the Node inspector enabled accepted injected JavaScript that decrypted and dumped the vault. In KeePassXC, the key material used by the browser extension pairing channel could be read from browser files, exposing entries. A browser-only manager was decrypted automatically when driven through Selenium.

The closing recommendations target developers: enable the hardened runtime and review its exceptions, notarize distributed software, disable risky Electron fuses, and penetration test applications. The takeaway is that these protections are only as strong as their exceptions and the weakest component around them, such as the browser.