Many Mac app developers use the Sparkle framework for updating their apps, but a recent security vulnerability discovery puts your Mac at risk. Here’s what you can do about it.

Apps using older Sparkle versions over http are vulnerable

Ars Technica posted a troubling article about the http man-in-the-middle security vulnerability that was discovered in the well-used Sparkle Framework. Here’s the original article with lots of technical detail.

Sparkle updated their code immediately to patch, in release 1.13.1, but developers using the framework have to do the work to update to 1.13.1, and make sure all connections are done over https.

Icon - The Sparkle Project
Icon: The Sparkle Project
Icon - The Sparkle Project
Icon: The Sparkle Project

Which of my apps use which version of Sparkle?

There’s a big list of apps that use Sparkle, but rest assured, if you’re a Mac user, your apps are likely using it.

Ars technica user “ryanr” shows a Terminal command that can be used to list up what apps on your system are using Sparkle, and what version.

find /Applications -path '*Autoupdate.app/Contents/Info.plist' -exec echo {} \; -exec grep -A1 CFBundleShortVersionString '{}' \; | grep -v CFBundleShortVersionString

However, if you use brew cask to install like I do, your apps are located in a different folder. To get their information, just change the path to /opt/homebrew-cask/Caskroom like so:

find /opt/homebrew-cask/Caskroom -path '*Autoupdate.app/Contents/Info.plist' -exec echo {} \; -exec grep -A1 CFBundleShortVersionString '{}' \; | grep -v CFBundleShortVersionString

In addition, brew and brew cask, as well as other systems, might install under ~/Applications under your home folder. So you can do:

find ~/Applications -path '*Autoupdate.app/Contents/Info.plist' -exec echo {} \; -exec grep -A1 CFBundleShortVersionString '{}' \; | grep -v CFBundleShortVersionString

… and so on, if you use different locations from the standard /Applications.

What you can do

First, what you can do is keep after the developers of the apps you use, and keep your apps updated. Ping the developers on Twitter or via email…

… and update your apps.

Ars offers this advice:

People who aren’t sure if an app on their Mac is safe should consider avoiding unsecured Wi-Fi networks or using a virtual private network when doing so.

Having read a bunch of other posts, it appears this is not just a Sparkle problem, critical though that is, but rather a fundamental bug in OS X itself. OS X sets Finder for FTP and AFP links, but Finder is where the vulnerability is.

So, here’s what you can do from a practical perspective:

  1. As just above, nag the devs of your apps to confirm they are set up to handle updates via Sparkle securely.
  2. If you don’t have any FTP client installed, install and run Firefox once, to get it to handle ftp:// links. If you have an FTP client like Transmit installed, go into its preferences and set it as the default FTP hander.
  3. If you have a Finder alternative like Path Finder, you can set it to handle FTP and AFP .
  4. Confirm in System Preferences, Security & Privacy, General tab, that you have “Allow apps downloaded from:” set to “Mac App Store and Identified Developers” or stronger.
  5. Make it harder for hackers by not using free, unencrypted WiFi .

What didn’t work:

  1. I tried duti but it does not work, even if I compile it myself. Settings seem to “take” then are reverted quickly.
  2. A System Preferences Panel app called “RCDefaultApp” that I used to use in older versions of OS X, no longer works in El Capitan version 10.11.
  3. There’s no easy, apparent way to use Apple’s native lsregister to do these URL handler settings.

Encryption is Critical

Thinking about this incident, it really shows you how important good encryption is, and why it should be a standard. Generally speaking, boo to the US legislators pining to remove encryption.

Updates

11 Feb 2016

  1. Codekit, Noun Project and AirParrot responded that their apps are not vulnerable.
  2. Peter Borg responded that Lingon is patched.
  3. Ben Barnett at Menial says “In progress. AppCast redirects to SSL-only, but app update needs to be released to fix properly.”
  4. 9labs say: “Yep, the latest AM (ed: that’s AudioMate) and SC updates include a patched version of Sparkle and use https:// by default.”

12 Feb 2016

Read in another post that this problem is more than just Sparkle. Suggested solution to use duti does not work, so I summarized a few steps you can take, above.

13 Feb 2016

  1. Flyingmeat says: “Acorn 5 uses https for updates, so it’s not a problem for us.”
  2. Zetetic (Codebook) says their AppCast is running over HTTPS .

14 Feb 2016-02

  1. Bombich software says their Carbon Copy Cloner uses only secure https to update, and that “that’s been the case for a while”.
  2. Atlassian software says their HipChat is not affected, because “HipChat uses https protocol to ensure the security of all data traffic. This creates a secure channel between the end user and the server preventing MITM (Man In The Middle) attacks.”