Security vulnerability — please update Sparkle ASAP

[kornelski]

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]

Fixed in a6e9c8a and 70f6929

[kornelski]

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]

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

[kornelski]

#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]

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]

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.

[alinebee]

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]

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]

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

[alinebee]

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]

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.