Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sparkle security vulnerability #60

Closed
JamesMcMahon opened this issue Feb 10, 2016 · 8 comments
Closed

Sparkle security vulnerability #60

JamesMcMahon opened this issue Feb 10, 2016 · 8 comments

Comments

@JamesMcMahon
Copy link

Older versions of Sparkle have a rather serious security vulnerability in it that allows a man in the middle attack to remote execute code during an update check.

All Sparkle versions older than 1.13.1 which fetch appcast or release notes over insecure HTTP connection are vulnerable to a man-in-the-middle attack that can lead to disclosure of local files or remote code execution.

Applications using Sparkle with HTTPS appcast feed URLs and HTTPS release notes links (if any) are safe.

More details at:

Only update URLs not using HTTPS are affected. I haven't tested the vulnerability with Boxer but I assume it is at risk since the version of Sparkle is 2 years old at this point.

@alinebee
Copy link
Owner

Yupppppp, all versions of Boxer will be vulnerable to this (though not standalone apps, so GOG's bundles are fine), and it's serious enough to warrant an urgent version update for 1.3.2. I'll need to sort out an SSL certificate for Boxer's webhosting first, as currently nothing on there can be served over HTTPS.

Unfortunately the fixed version of Sparkle will break legacy support for 10.5 and 10.6, but I expect anyone stuck on those is all kinds of vulnerable as it is.

@fingolfin
Copy link

@alunbestor You can also try to only apply the two commits fixin the issue -- not sure if that will work with your old Sparkle version, but you could try.

And of course using https for the appcast URL would be a fix, too (and a good idea in general ;-)

@alinebee
Copy link
Owner

Yeah HTTPS is non-negotiable at this point, but it will still require an update to Boxer itself to point it at the new https URL; simply making the site redirect from http to https would still leave the app vulnerable to a MITM attack.

Further: Boxer is using an ancient (1.5b6) version of Sparkle from 2008, which was the last version that included 10.5/PPC/32-bit intel compatibility. The release notes for that version have since been updated to state that it is not compatible with OS X 10.11.

I have yet to test to find out what that caveat means: i.e. whether old apps using that version cannot check for updates at all on 10.11 (in which case, are they still vulnerable to the exploit?) or if Sparkle will continue working as-is in old apps (exposing them to the exploit) but will break in apps that are newly-compiled against the 10.11 SDK (because of 10.11's app transport policy restrictions, which prevent apps compiled against 10.11 SDK from using unsecured HTTP.)

(Edit: this reply from a Sparkle maintainer indicates that existing apps linking Sparkle 1.5b6 will continue to update on 10.11, and the caveat was referring to a 10.11 Gatekeeper issue.)

@plessbd
Copy link

plessbd commented Feb 12, 2016

For https, you might want to look into https://letsencrypt.org/ free ssl certs. Not sure if that is the reason or if it is a technological one

@alinebee
Copy link
Owner

Ahh sorry, by "non-negotiable" I meant "of course I'll be switching Boxer's update feed to https", not "I'm not able to do that at this time."

I'm still evaluating my SSL options with Boxer's current hosting setup, but in any case I plan to push a commit and binary update out this weekend that will point to an (as-yet-unavailable) https endpoint for future update checks.

alinebee added a commit that referenced this issue Feb 15, 2016
This addresses the security vulnerability detailed in issue #60.
alinebee added a commit that referenced this issue Feb 15, 2016
Addresses security vulnerability described in issue #60.
@alinebee
Copy link
Owner

TL;DR: if you're building Boxer from source, please rebuild from master to close the Sparkle vulnerability. If you're using the stable 1.3.2 release, an update is still on the way.

Progress update:

  • Boxer's webhosting can now serve update feeds over HTTPS.
  • Boxer's master branch now fetches update feeds over HTTPS, and replaces Sparkle 1.5b6 with a version of 1.6 into which I've integrated the necessary security fixes. (1.6.x is the last version that retains i386 support.) If you're building your own Boxer, please pull and rebuild from source to close the Sparkle vulnerability.
  • I've prepared an updated app bundle based on 1.3.2, which uses the same Boxer binary as 1.3.2 but replaces the Sparkle framework. (I want to avoid rebuilding Boxer 1.3.2 against the 10.11 SDK, as that would change its behaviour and UI appearance in subtle ways that I don't want to have to fix.)
  • The release of an official update to 1.3.2 is stalled while I fight with 10.11 over code-signing and Gatekeeper issues. Gatekeeper on 10.11 is rejecting newly-signed apps for me, and until I get that fixed I can't release the update.
  • Once properly signed, the update still needs to be tested to ensure that not only will it be downloaded correctly but that it will be able to download future updates correctly.
  • The update will artificially bump the minimum OSX version requirements to 10.6. It is no longer possible to build PowerPC binaries with modern XCode versions, and if the minimum version was left at 10.5 then any lingering PPC users would receive an update that breaks the app altogether for them. If any such users do still exist, I'd rather leave them with an unsupported and vulnerable version of the app than no version at all.

My apologies for the slow movement on this issue, but there's a lot of points of failure to worry about and I want to do it right. Though the actual application fix was trivial, serving an official update that migrates to a new updater and a new update location is easy to screw up: if set up incorrectly, the 'fixed' app version might end up still vulnerable and unable to fetch any future updates.

@JamesMcMahon
Copy link
Author

Thanks for all your hard work Alun on addressing this issue.

I know it must be a pain to go back to the old codebase as you work on Boxer 2.0.

@alinebee
Copy link
Owner

I have released two official updates to address this vulnerability: Boxer 1.4.0 for OS X 10.6 and above, and Boxer 1.3.3 for OS X 10.5 and PowerPC. Users should see Boxer prompt them to update when Sparkle's weekly update check swings around.

1.4.0 switches to HTTPS and integrates the fixed version of the Sparkle framework. This is the version everyone should use (unless you're building 2.0 from source, which also has the fixes now.)

1.3.3 is a no-man-left-behind version for PowerPC compatibility only: it continues to use the old unpatched Sparkle version but switches to HTTPS to prevent the vulnerability from being exploited. Unless you're stuck on 10.5 in the year of our lord 2016, grab 1.4.0 instead.

These releases are otherwise binary-identical to 1.3.2: they do not introduce new functionality or fix any other bugs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants