Incorrect default permissions enable local privilege escalation in Canonical Multipass on macOS

In Canonical Multipass up to and including version 1.15.1 on macOS, incorrect default permissions allow a local attacker to escalate privileges by modifying files executed with administrative privileges by a Launch Daemon during system startup.

The Canonical advisory identifies Multipass on macOS versions <= 1.15.1 as affected and lists 1.16.0 as patched. The CNA structured affected data expresses the vulnerable range as semver < 1.16.0, with default_status set to unaffected; this is the primary boundary for this record. A later Canonical release note for 1.16.3 mentions a macOS binary ownership change and two vulnerability fixes, but the reviewed evidence does not explicitly revise this record's range. Treat coverage of 1.16.0 through 1.16.2 as requiring separate verification against Canonical follow-up guidance.

Canonical Multipass on macOS installs files with default permissions that allow other users to modify them. The multipassd component is invoked by a Launch Daemon during system startup, but the binary can be owned by the local user instead of root. An attacker with local access and the ability to write the affected file can replace or modify the binary so that attacker-controlled code runs when the Launch Daemon starts. The vendor advisory describes execution in a privileged context and arbitrary actions as root. The available evidence does not confirm other deployment paths or configurations beyond the Launch Daemon and multipassd path described by the advisory.

The vulnerability is locally reachable and not network-reachable according to the available evidence. An attacker needs a local account or equivalent local access with sufficient ability to modify the affected file. The documented attack model describes low complexity and low privileges required. User interaction is inconsistent across the published assessments: the CNA assessment records interaction as required, while the NVD assessment records no interaction; the vendor demonstration uses a system restart to cause the Launch Daemon to execute the replaced binary. The supplied record marks a public exploit as available, and the vendor advisory contains a proof-of-concept demonstration. The evidence does not establish exploitation in a specific campaign.

Successful exploitation allows attacker-controlled code to run as root within the macOS host's security context. The technical outcome can include loss of confidentiality, integrity, and availability for resources accessible to root. The recorded scope is unchanged, so the available evidence describes impact within the security authority of the affected host. Exploitation requires local presence and the ability to modify the vulnerable file; the record does not establish remote exploitation or escape beyond the host security boundary.

Successful exploitation can give a local attacker highly privileged control of a macOS system running Multipass. Possible consequences include access to data available to root, modification of system files or configuration, installation of persistent changes, and disruption of services or workloads on the host. The operational risk is greater on shared workstations, developer systems, and endpoints that execute code from multiple sources. The available evidence does not confirm a specific breach, data loss event, or impact beyond the affected host.

1. Upgrade Multipass on macOS to 1.16.0, which Canonical lists as patched for this record.
2. If the update cannot be applied, use the vendor workaround by changing the owner of /Library/Application Support/com.canonical.multipass/bin/multipassd to root:wheel, then recheck the file's write permissions.
3. For deployments on 1.16.0 through 1.16.2, do not treat the original advisory alone as proof that every later branch is covered. Check current Canonical guidance, particularly because the 1.16.3 release note documents a separate macOS binary ownership change.
4. After updating or applying the workaround, verify the owner and permissions of multipassd, confirm that the Launch Daemon references the expected binary, and review the file for unauthorized prior modification.

1. Inventory macOS systems with Canonical Multipass installed and compare their versions with the affected boundaries in affected_summary.
2. Inspect /Library/LaunchDaemons/com.canonical.multipassd.plist and determine whether its ProgramArguments entry invokes /Library/Application Support/com.canonical.multipass/bin/multipassd.
3. Check the owner and permissions of /Library/Application Support/com.canonical.multipass/bin/multipassd. A concerning state is ownership by a local user or write access for an unprivileged user.
4. Review unexpected changes to the multipassd binary, system restart events, and Launch Daemon execution of that binary. This is precautionary monitoring, not a vendor-confirmed IOC.
5. Absence of suspicious log evidence does not prove that a system is safe. Combine version, ownership, and write-permission checks.