Sparkle 2.7.3 - Important security fixes for local exploits

[zorgiepoo]

2.7.3 includes important security fixes that addresses local privilege exploits (#2763). These issues and fixes have been identified/reported and reviewed by @Karmaz95 .

The nature of them can be exploited by installed malware running on the system and the in-depth details are as follows:

TCC bypass using the Downloader XPC Service:

• An attacker could use the downloader service from an installed application to "download" a file that TCC should otherwise prevent it from having access to (e.g. in ~/Desktop, ~/Documents, ~/Downloads directories)
• This attack works by using the installed application's already approved TCC access to one of these directories or by tricking the user into asking them to approve access for one of those directories on behalf of that application.
• This is fixed through improved validation of the request URL, and by enforcing code signing requirement (for apps that use Apple-issued certificates). Karol made a PoC for this (I have not tried it myself but believe it).
• This affects even apps that don't enable/use the downloader service (few apps use this service).
• This should not impact Sparkle versions < 2.6 (because the downloader service used to be sandboxed by default preventing such file access, assuming it was correctly signed) and Sparkle 1 does not include a downloader service. The attack may also not be relevant on macOS 10.13. (Older Sparkle versions are vulnerable to other security issues however).
• This does not impact apps that have chosen to remove the downloader service to save disk space from not using it
• This does not impact apps that do use the downloader service and have chosen make a custom build of Sparkle to sandbox the service (by setting a custom XPC_SERVICE_BUNDLE_ID_PREFIX and uncommenting DOWNLOADER_SANDBOXED_ENTITLEMENTS)

Root privilege escalation by letting Sparkle update an arbitrary bundle with an arbitrary package installer (pkg), which comes in two flavors:

• An attacker could spawn the Installer XPC Service from an installed application to bring up an authorization dialog with an arbitrary prompt message which tricks the user into installing an update on a malicious/fake bundle that is set up to execute an arbitrary pkg workload.
  • This attack requires the user to enter their user/password credentials to allow it. Karol built a PoC for demonstrating this.
  • This affects even apps that don't enable/use the installer service (sandboxed apps use this service)
  • This does not impact non-sandboxed apps that have chosen to remove the installer service to save disk space from not using it
• An attacker could send an very well-timed XPC message to the Autoupdate tool to install an update on a malicious/fake bundle that is set up to execute an arbitrary pkg payload
  • This potential attack is a race condition that relies on sending a message to the Autoupdate tool before the app sends its first message, which it tries to do after spawning the tool. Autoupdate rejects the second simultaneous connection. Additionally, Autoupdate must be spawned as root to install an update requiring user authorization. A PoC was not yet built for exploiting this timed window but likely feasible.
• These attacks do not impact apps that have made a custom build of Sparkle by disabling SPARKLE_BUILD_PACKAGE_SUPPORT (this is rarely done).
• Sparkle 1 doesn't have XPC endpoints and isn't exploited by this specific method of attack. However its underlying architecture is not built to prevent well-timed file/payload substitution attacks from installed malware.
• These issues are fixed through improved validation of the client against the bundle to update, and by enforcing code signing requirement (for apps that use Apple-issued certificates). Code signing is strongly recommended.

One important consequence is that apps that install package updates may not be able to test Sparkle in a development environment easily where Sparkle's tools are often not specially signed. Please try testing Sparkle either from a notarized version of your app, or from a version of your app that was installed by your package installer.

This fix is also included in 2.8, which is also revamped for Tahoe compatibility.

I also updated the Security & Reliability page.

[zorgiepoo]

A potential crash was reported/fixed in #2765 for apps that have a Team ID starting with a number.

2.7.3 and 2.8.0-beta.3 have been released with this fix. Please don't use 2.7.2 or 2.8.0-beta.2

[ychin]

Hi, just some questions on some finer details about this.

These attacks do not impact apps that have made a custom build of Sparkle by disabling SPARKLE_BUILD_PACKAGE_SUPPORT (this is rarely done).

Is there another way to disable PKG support without requiring a manual re-compilation? I prefer using the officially distributed Sparkle binaries since that seems to be what everyone uses and I like using the standardized way to set up Sparkle, but it does appear to be bundling a potential attack vector for a functionality that my app does not need. I do agree that even with the original unfixed vulnerability it required root permission for Autoupdate or user/password for the Installer XPC which does seem like a fairly unlikely exploit (if they get the user to run programs in root they can do a lot of other damage already).

An attacker could use the downloader service from an installed application to "download" a file that TCC should otherwise prevent it from having access to (e.g. in ~/Desktop, ~/Documents, ~/Downloads directories)

Is there a reason why the Downloader XPC service should have the ability to download arbitrary URLs to such arbitrary folders? Is it just because that's how the contract between the Installer and Downloader works and the Installer prefers to set which folder it wants the files to be downloaded to and just tell the Downloader where to download to? It does seem like a powerful ability for a service to have if it's exposed for anyone to invoke (albeit now blocked by code signature requirement).

Generally I'm also wondering what happens if we have an app that is not code signed. This is not an unlikely situation. A developer just doing local development is likely to build ad-hoc signed apps for local testing. Homebrew also distributes ad-hoc signed applications (that said, most Sparkle-enabled apps should usually be distributed via Homebrew casks instead of Homebrew but there are exceptions). Were the other protections enough without the code signature checks?

[zorgiepoo]

Is there another way to disable PKG support without requiring a manual re-compilation?

Nope. I'm not sure if there's a good way to make this possible but I share your concern. (I'm also going to remove a deprecated interactive package installation type in next release that should no longer be used).

The downloader service should have checked the request URL was not a file:// and only http(s) which would have prevented that issue (and the fix makes this change, too).

Autoupdate now does not install package updates associated to arbitrary bundles if it's unsigned/adhoc-signed (in other contexts, Sparkle may be used to update other bundles). There are safeguards, for unsigned/adhoc-signed apps, that the update bundle must contain the Autoupdate tool and the tool be owned by root on disk. That can make development adhoc testing a bit of a more hassle, which I mentioned in the first post.

Production builds that have Autoupdate and XPC Services code signed will have additional checks now, denying clients whose development team does not match.

tldr; there are safeguards even for unsigned/adhoc-signed apps without breaking them (albeit extra annoyance with pkg development) but signed apps have better security. I have thought about disabling pkg update support for unsigned/adhoc-signed builds, but it hasn't come to that yet..

[ychin]

Right that makes sense. Thanks!