apple-knowledge

The macOS security model relies on a complex interplay of hardware (SEP), firmware (iBoot, sepOS), and local policies. Key areas of concern for security researchers and developers include:

• Encryption of Boot Components: Unlike Intel EFI, iBoot and sepOS are encrypted, making independent verification of the early boot process difficult.
• Local Policy Reductions: The recoveryOS policy is stored on disk and can be subject to lpol reductions to asmb (Apple Secure Multi Boot), potentially targeting undocumented smb5 values.
• Persistence of Identity Keys: Because the Owner, System, and User Identity Keys are backed by the SEP, a failure to reset boot-policy-digests, xART, and nonce-seeds during an erase can allow older policies to be re-applied.
• Bootloader Re-entrancy: There is no technical measure preventing fuOS from booting into iBoot or macOS, which could allow for insertion into the boot chain if a proper local policy is present.
• Rosetta Entitlement Retention: Rosetta can retain entitlements during translation, creating a risk where an attacker could pre-poison the AoT cache with malicious translations for core dylibs.

The M1 architecture introduces several security regressions compared to previous generations. A primary concern is the use of an encrypted boot-loader (iBoot), which prevents external security verification and independent auditing. While the applevm2 stack leaves much of the M1 boot process visible, the lack of full source access prevents complete verification of the secure-boot-chain.

Key identified weaknesses include:

• Lack of External Measurement: There is no high-assurance path to perform measurements (such as hashing regions or reading APTickets) without performing a full device restore.
• SecureROM Relocation: SecureROM copies its executable region to mutable SRAM. Because this code exists in DRAM, any coprocessor with a DMA path or incomplete SRAM clearing could potentially compromise SecureROM guarantees.
• ACE (USB-C) Vulnerability: The ACE (USB-C port controller) can push a device into DFU mode without user interaction, lacking a requirement for a physical key press to prevent misuse.
• PMP/PMGR Risks: Malicious PMP firmware can prevent the DFU flow because the PMP handles the DFU chord. The author suggests returning to a ROM-based DFU entry method.

This document outlines security vulnerabilities and proposed mitigations within the iOS DataMigration.framework and its associated XPC workers. The core issue is that the migration system uses a highly privileged plugin host process that runs various dynamic plugins. Because entitlements are tied to the process rather than the specific plugin, a vulnerability in a single plugin (e.g., a contact migration plugin) can allow an attacker to pivot to unrelated high-privilege systems (e.g., keychain or profiles).

Key security weaknesses identified include:

• Over-entitled processes: The plugin host holds a strict superset of all entitlements needed by its plugins.
• Lack of plugin-specific entitlements: There is no mechanism for a dynamically loaded shared object to declare its own specific entitlements (like com.apple.datamigration.plugin).
• Atomic dlopen risks: The current dlopen mechanism does not allow for a 'preflight' state where a module is mapped as Read-only (R) and inspected for authenticity (via Trust Cache/CDHash) before being granted Execute (X) permissions.
• execve descriptor persistence: Entitlements checked for an initial process might persist through an execve call, allowing a new binary to inherit open, entitled connections.
• MobileDevice Framework downgrades: The ability to modify MobileDevice components on the Data partition of macOS allows for downgrading system frameworks without being an entitled process.

The QEMU Gadget Device USB Stack aims to solve the limitations of traditional USB virtualization (which focuses on exposing physical/virtual devices to a guest OS) by providing a way to test and connect ARM-style 'gadget mode' devices.

Key architectural goals include:

• Low-level control: Unlike USB over TCP/IP, this stack must support device enumeration, protocol errors, and precise control of SETUP packets, endpoints, stalls, and enumeration to enable fuzzing and low-level testing.
• Decoupled lifetimes: The USB bus lifetime should be independent of both the device and the host. This is achieved by using a separate process (a virtual USB controller or usbd) so that a system restart or device reset doesn't destroy the underlying connection.
• OS Independence: The protocol must be OS-agnostic to allow communication between different operating systems.
• Security and Local Connectivity: Local connectivity should avoid TCP by default. It proposes a capability model using separate sockets for the 'gadget' end and the 'host' end to allow for distinct user/group permissions, and the ability to restrict access by USB PID/VID and Classes.
• Async-first design: Since kernel transports are asynchronous, the stack supports async submission/completion. Synchronous semantics are simulated at the client end using timeouts and mutexes/semaphores.
• Fuzzing support: The stack allows for the submission of RAW frames in addition to traditional Control/Bulk types to support malformed and non-sensical frames.