Summary
AppInstaller post-stage-1 XPC listener accepts unvalidated connections, allowing spoofed appcast item data injection.
Details
Autoupdate/AppInstaller.m's shouldAcceptNewConnection: only enforces SUCodeSigningVerifier validateConnection: before stage 1 completes. After _performedStage1Installation = YES, new connections to the registered Mach service <bundleId>-spki are accepted from any local process without team-ID or code-signing checks.
The following chain of events enables an attacker to inject a spoofed SPUSentUpdateAppcastItemData payload:
- Installer finishes unarchiving the update successfully (
_willCompleteInstallation is set).
- The app responsible for updating the bundle crashes or is forcefully quit before it has a chance to send
SPUSentUpdateAppcastItemData to the installer. There is no user interaction between the prior step and this one, so the timing window is tight.
- After stage 1 of the installer is performed (
_performedStage1Installation = YES), but before final installation completes (since all services are cleaned up by then), an attacker process connects to the <bundleId>-spki Mach service - no code-signing validation is enforced - and sends a spoofed SPUSentUpdateAppcastItemData message containing an attacker-crafted SUAppcastItem.
- A Sparkle-aware app that checks for updates on the bundle being updated launches before installation completes. The progress agent re-broadcasts the spoofed
SUAppcastItem on its <bundleId>-spks status service, and the launching app displays attacker-controlled release notes (name, version, critical flag).
Note: Sparkle can be used to update other app bundles, so the "app doing the updating" and the "app being updated" are not necessarily the same bundle.
In the system-domain case (SPUUsesSystemDomainForBundlePath = true), the AppInstaller runs as root via SMJobSubmit to kSMDomainSystemLaunchd, and the Mach service is reachable by any local user process.
Affected versions: 2.x branch including 2.9.1.
Impact
A local user-level process can inject a forged SUAppcastItem (arbitrary name, version, critical flag) into the progress agent's status broadcast. Other Sparkle-aware clients on the system will display attacker-controlled release notes as authoritative installation state.
The integrity of the installed code is not affected - the bundle moved into place is the legitimate, signature-validated update from stage 1. The impact is limited to UI spoofing of installation metadata.
Remediation
Enforce SUCodeSigningVerifier validateConnection: on all new connections regardless of installation stage, or disallow SPUSentUpdateAppcastItemData after the active connection invalidates.
References
fg0x0 Reporter
Summary
AppInstaller post-stage-1 XPC listener accepts unvalidated connections, allowing spoofed appcast item data injection.
Details
Autoupdate/AppInstaller.m'sshouldAcceptNewConnection:only enforcesSUCodeSigningVerifier validateConnection:before stage 1 completes. After_performedStage1Installation = YES, new connections to the registered Mach service<bundleId>-spkiare accepted from any local process without team-ID or code-signing checks.The following chain of events enables an attacker to inject a spoofed
SPUSentUpdateAppcastItemDatapayload:_willCompleteInstallationis set).SPUSentUpdateAppcastItemDatato the installer. There is no user interaction between the prior step and this one, so the timing window is tight._performedStage1Installation = YES), but before final installation completes (since all services are cleaned up by then), an attacker process connects to the<bundleId>-spkiMach service - no code-signing validation is enforced - and sends a spoofedSPUSentUpdateAppcastItemDatamessage containing an attacker-craftedSUAppcastItem.SUAppcastItemon its<bundleId>-spksstatus service, and the launching app displays attacker-controlled release notes (name, version, critical flag).Note: Sparkle can be used to update other app bundles, so the "app doing the updating" and the "app being updated" are not necessarily the same bundle.
In the system-domain case (
SPUUsesSystemDomainForBundlePath = true), the AppInstaller runs as root viaSMJobSubmittokSMDomainSystemLaunchd, and the Mach service is reachable by any local user process.Affected versions: 2.x branch including 2.9.1.
Impact
A local user-level process can inject a forged
SUAppcastItem(arbitrary name, version, critical flag) into the progress agent's status broadcast. Other Sparkle-aware clients on the system will display attacker-controlled release notes as authoritative installation state.The integrity of the installed code is not affected - the bundle moved into place is the legitimate, signature-validated update from stage 1. The impact is limited to UI spoofing of installation metadata.
Remediation
Enforce
SUCodeSigningVerifier validateConnection:on all new connections regardless of installation stage, or disallowSPUSentUpdateAppcastItemDataafter the active connection invalidates.References