Wojciech Reguła: Izolacja aplikacji na macOS i jej exploitacja | OMH 2024

### Overview Wojciech Reguła presents a deep dive into macOS application isolation and process control mechanisms, debunking the common assumption that macOS behaves like traditional Linux. The talk demonstrates how macOS enforces process isolation even between tasks owned by the same user ID (UID), how mechanisms like System Integrity Protection (SIP) and Hardened Runtime enforce these boundaries, and how architectural oversights or insecure configurations in popular password managers allow attackers to execute code and steal credentials.

### Key Topics - **macOS Architecture vs. Linux**: macOS is a hybrid kernel combining FreeBSD (POSIX compliance, process management, signals) and Mach (tasks, ports, multitasking, virtual memory). Unlike traditional Unix/Linux where processes with identical UIDs can inspect and control each other, macOS prohibits cross-process control unless explicitly allowed via entitlements such as `com.apple.security.get-task-allow`. - **System Integrity Protection (SIP) & TCC**: SIP acts as an enforced global sandbox across the operating system (rootless model). Breaking process isolation can allow attackers to hijack entitlements, bypass Transparency, Consent, and Control (TCC) privacy prompts, escalate privileges to root, or defeat system protections. - **Process Injection Requirements & AMFI**: Controlling another process requires acquiring its task port via `task_for_pid`, which is strictly audited by Apple Mobile File Integrity (AMFI) and Taskgated. It is blocked for platform binaries and Hardened Runtime processes unless debugging entitlements exist. - **Hardened Runtime & Entitlement Exceptions**: Hardened Runtime blocks code injection, `DYLD_INSERT_LIBRARIES` (the macOS equivalent of `LD_PRELOAD`), and dynamic library hijacking. However, exceptions such as `com.apple.security.cs.disable-library-validation` allow arbitrary dynamic library loading.

### Technical Details & Case Studies Reguła analyzes exploitation vectors across various password managers: - **MacPass**: While Hardened Runtime was active, library validation was disabled to support plugins loaded from `~/Library/Application Support/MacPass`. Attackers can drop an untrusted dynamic library or plugin into this unconfined directory, enable `loadIncompatiblePlugins` in defaults, and execute code inside MacPass to dump the database and master password. - **Bitwarden**: Distributed via the Mac App Store, where Hardened Runtime is merely recommended rather than enforced by Apple's notarization pipeline. Due to the missing Hardened Runtime flag, standard library injection via `DYLD_INSERT_LIBRARIES` succeeded directly, allowing a keylogger to capture the master password. - **NordPass**: An Electron-based application where Electron debugging fuses were left open (`enable_node_cli_inspect_arguments`). Using the speaker's open-source tool `electronizer`, arbitrary JavaScript was injected via Chrome DevTools protocol over WebSockets to extract the master password. - **KeePassXC**: Examined in the context of browser integration. While IPC communication uses asymmetric cryptography, the browser extension stores the private communication key in unprotected browser files without sandboxing. An attacker can read the key with a single bash command, spoof the extension, and retrieve credentials. - **Proton Pass**: Operates purely as a browser extension, keeping decryption and secrets inside the browser's JavaScript runtime. Automation frameworks like Selenium can instrument the browser directly to read decrypted secrets.

### Takeaways & Developer Recommendations - Always enable **Hardened Runtime** and eliminate dangerous entitlement exceptions like disabled library validation whenever possible. - Keep **SIP (System Integrity Protection)** enabled across all managed environments (`csrutil status`). Disabling SIP degrades macOS security guarantees. - Implement macOS App Sandboxing, which prevents unauthorized processes from reading application-specific directories. - In Electron applications, disable debugging flags and developer inspection fuses in production builds. - Conduct third-party security assessments rather than relying solely on automated store review mechanisms.