-
Notifications
You must be signed in to change notification settings - Fork 141
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
Comments
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. |
@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 ;-) |
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.
(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.) |
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 |
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. |
This addresses the security vulnerability detailed in issue #60.
Addresses security vulnerability described in issue #60.
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:
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. |
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. |
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. |
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.
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.
The text was updated successfully, but these errors were encountered: