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

Security vulnerability — please update Sparkle ASAP #720

Closed
kornelski opened this Issue Jan 29, 2016 · 11 comments

Comments

Projects
None yet
6 participants
@kornelski
Copy link
Member

kornelski commented Jan 29, 2016

HTTP MITM vulnerability

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.

The vulnerability is fixed in version 1.13.1. Patches for older versions are available: a6e9c8a,
70f6929

Thanks to Radoslaw Karpowicz for reporting the vulnerabilty.

@kornelski

This comment has been minimized.

Copy link
Member

kornelski commented Jan 29, 2016

Fixed in a6e9c8a and 70f6929

@kornelski kornelski closed this Jan 29, 2016

@kornelski

This comment has been minimized.

Copy link
Member

kornelski commented Jan 29, 2016

Yes, if the appcast is sent over HTTP. The vulnerability is in the handling of XML and the webview for release notes, which a MITM attacker can manipulate.

@reedloden

This comment has been minimized.

Copy link

reedloden commented Jan 31, 2016

Note that one part of this vulnerability was reported several years ago (#169).

@kornelski

This comment has been minimized.

Copy link
Member

kornelski commented Jan 31, 2016

#169 was "fixed" by changing options to NSXMLNodeLoadExternalEntitiesSameOriginOnly, but the trap was that the origin was file://, rather than the network origin of the appcast.

@glyph

This comment has been minimized.

Copy link

glyph commented Feb 1, 2016

Is there a way for users to protect themselves against this issue for applications that haven't updated yet? An external tool that can update Sparkle-based applications, perhaps?

@zorgiepoo

This comment has been minimized.

Copy link
Member

zorgiepoo commented Feb 1, 2016

FYI: Sparkle requires OS X 10.7 or later now. 10.6 has been dropped a while back. If you're a developer of an application that has been supporting 10.6 (eg: Adium, VLC) this may apply to you. cc @pornel probably worth mentioning in the release notes.

@alunbestor

This comment has been minimized.

Copy link

alunbestor commented Feb 10, 2016

I'm the developer of Boxer. Boxer uses Sparkle 1.5beta6 from way back in 2008, which was the last Sparkle release that retained 10.5/PPC support. Boxer checks for appcasts over unsecured HTTP; clearly I need to switch to HTTPS as soon as possible, and should update Sparkle at the same time.

However, my concern is this note in the release notes for 1.5b6: "Sparkle 1.5 is not compatible with OS X 10.11 El Capitan. Please use a newer version of Sparkle."

Does that caveat mean that existing apps using Sparkle 1.5 can no longer fetch updates on 10.11 - and if so, are such apps still vulnerable to this exploit on 10.11?

Or, does it mean existing apps using Sparkle 1.5 can continue to fetch updates on 10.11 (and remain vulnerable to the exploit), but apps newly compiled against the 10.11 SDK cannot fetch updates on 10.11 with Sparkle 1.5?

@kornelski

This comment has been minimized.

Copy link
Member

kornelski commented Feb 10, 2016

If I remember correctly Sparkle 1.5 doesn't pass gatekeeper check on El Capitan due to a broken symlink it bundles.

It won't cause users to be stuck running un-updateable app, because they either have allowed the app to run anyway, or have blocked apps from "unidentified developers" running at all and OS X will tell them to trash the app.

@jakepetroules

This comment has been minimized.

Copy link
Contributor

jakepetroules commented Feb 10, 2016

Do you really need to support OS X 10.5? That version is beyond dead.

@alunbestor

This comment has been minimized.

Copy link

alunbestor commented Feb 10, 2016

No, but I do need 32-bit binary compatibility. The app's last public release was 4 years ago and is 32-bit-only; modern Sparkle versions cannot be compiled for 32-bit (they rely on ARC, which is not compatible with the legacy x86 ObjC runtime). The app cannot be recompiled for 64-bit without a lot of work and risk.

That means identifying a Sparkle version that still supports x86 and patching it, and at that point one may as well leave 1.5 in place and focus on switching to HTTPS (which prevents the vulnerability being exploited anyway.)

TL;DR: for legacy apps like this it's often not as simple as just dropping in a new framework version and deciding to leave users behind. And even when it is that simple, a security fix update should not change the system requirements of an app unless absolutely necessary.

@kornelski

This comment has been minimized.

Copy link
Member

kornelski commented Feb 11, 2016

a security fix update should not change the system requirements of an app unless absolutely necessary.

The fix doesn't introduce new system requirements in versions that we support, and we've dropped 32-bit almost two years ago.

The patches can be applied to the 2008 version if you can build that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment