Are You Affected by the Sparkle Vulnerability? Here's How to Find Out [Tutorial]

Are You Affected by the Sparkle Vulnerability? Here's How to Find Out [Tutorial]

February 10, 2016 11:35 EST • Alexandre Vallières-Lagacé • 3 minute read

This is a very important breach, but it can be mitigated by many factors so do not panic.

Sparklet is publishing a framework that can be included in your Mac OS applications to check a remote server for a new update and if there is one available, show a popup and the famous Install Update button we see very often.

What’s the problem?

The problem lies with the implementation of this framework by the developers of apps you love. They have to provide a URL to check for new updates and this URL does not absolutely have to be SSL encrypted and there lies the problem. By not being an https:// URL, a hacker could do a MITM (man in the middle) attack and insert his content in the response. This response can include a URL to download an infected application update and it can be used to gain full control of your computer.

What are the apps infected?

In order to find installed apps that have this framework, there is a way to list all apps that are currently using the Sparkle framework, but they do not differenciate between the version.

Here is the command that makes the round:

find /Applications -name Sparkle.framework | sed 's,/Applications/\(.*\)\.app/Resources/Info.*,\1,'

But then again, it is not sufficient information. This vulnerability can be mitigated with one simple step. If the developer used an HTTPS url for the Appcast, then you are safe. Sadly, they are no way to know this at the moment.

However, from the GitHub release page we know that Sparkle 1.13.1 has the vulnerability patched and it is now enforcing HTTPS for all AppCast URL. So what apps do you have that have an older version of the framework? I’m glad you ask!

Run this command to show your apps with Sparkle and the Sparkle version right next to them:

find /Applications -name Sparkle.framework | sed 's,/Applications/\(.*\)\.app/Resources/Info.*,\1,'|while read fname; do
  appname=$(echo $fname | sed -e 's/\/Contents\/Frameworks\/Sparkle\.framework//g' | sed -e 's/\/Applications\///g')
  version="$(defaults read "$fname/Resources/Info" CFBundleShortVersionString)"
  echo "$appname => $version"

This is the output running on my computer:

2016-02-10 10:06:31.863 defaults[14981:7648687] 
The domain/default pair of (/Applications/Antidote, CFBundleShortVersionString) does not exist
Antidote => 
Bartender => 1.10.0 git-439d4e3 => 1.5 Beta 6
Facebook => 1.5 Beta (git) => 1.5 Beta (git) => 1.5 Beta (git)
Google => 1.5 Beta (git) => 1.5 Beta (git) => 1.12.0 git-4e33285 => 1.11.1 => 1.5 Beta 6 => 1.11.1 => 1.5 Beta (git) => 1.5 Beta (git)
Sequel => 1.5 Beta (bzr) => 1.5 Beta (git) => 1.8.0 => 1.5 Beta 6 => 1.5 Beta (bzr) => 1.5 Beta (bzr)

You might have noticed that some apps (in my case Antidote 9) does not work with the script as they moved the framework to another non-standard folder. Using the output information above you can run this command to get the information:

defaults read /Applications/Antidote CFBundleShortVersionString

Basically, all my apps are using a version lower than 1.13.1 and they could all be using an HTTP URL. Sadly, there is no way to know for sure unless the app developer upgrades the framework to 1.13.1 or later.

As it is with these frameworks, developers rarely have an incentive to update them. If they still work, why not keep them as they are? Most of my apps are using a version of Sparkle released in 2008-2009… This was discussed on the Under the Radar #13 podcast by @marcoarment and @_davidsmith

If you were very thourough you could monitor your network traffic and sort out all of the URLs where connections are being made to on per app basis and see which of the apps connects to a non-secure URL. But that would require another very detailed tutorial.