1

&tldr; What prevents us from replacing an old Sparkle.framework with a newer Sparkle.framework?

Sparkle is a framework commonly used in Mac OS X applications to manage updates. Recently, a vulnerability to man-in-the-middle attacks was reported; and, due to the large number of well-known applications which use Sparkle, IT managers around the world are starting to lose sleep.

Some affected applications, like VLC, have reportedly already released a fix. However, since Sparkle has been around for so long, there are potentially many other applications which are no longer actively developed but which are still vulnerable to the same problem. We have encountered one such application already.

Since the Sparkle.framework is a run-time framework, it stands to reason that replacing the old (in many cases 1.5, or 1.6) code with newer (1.13.1) code within the application bundle will allow the application to run in many cases. So far, our light testing is an encouraging two for two (meaning, the application could start, and a check for updates would occur); but, while encouraging to the optimists, this is by no means a comprehensive answer.

So, reaching out to the professionals -- what are the drawbacks (or, impediments) to replacing old versions of Sparkle.framework in application bundles with the latest version? Could this in fact mitigate vulnerabilities while waiting for all of the affected applications to be updated.

The answer may change, depending upon the version of Sparkle currently used, and which function calls were supported by which version. It also depends if any function has been deprecated in newer versions of Sparkle, which is something I don't know.

Kent
  • 113
  • 1
  • 5
  • There are no drawbacks; old versions of Sparkle.framework should be replaced or at the very least be switched to https if not using it already. – l'L'l Feb 12 '16 at 15:50
  • The original question may not have been clear enough; but, I'm referring to replacing Sparkle.framework in apps which have been downloaded, and not in apps which we are developing ourselves. – Kent Feb 15 '16 at 02:23

1 Answers1

1

If you are the developer of an app, absolutely upgrade the framework and push out the updates. From the text that discusses replacing sparkle "within the application bundle" I'm going to presume you are contemplating fixing several apps that you have installed.

I would say that's not safe at all in general and it would be a much more effective countermeasure to just set the sparkle update variable to disable all updates. Since there are major changes in the code base between 1.5 and 1.10 (looking over the release notes the framework ditched 32 bit, ditched the old Obj-C runtime, ditched garbage collection and made numerous changes to the internal API) it would be highly risky to shove a newer sparkle into an older app unless you were to test each exhaustively or inspect the use of the framework / decompile the code.

I've been editing the Info.plist file to change the SUFeedURL key to point to https://172.0.0.1/app-name.xml for all the apps that have an http feels that's vulnerable to bad actors in control of compromised networks.

You could also disable automatic checks for those apps as well if you so desired. Here's a quick and dirty one line check for sparkle frameworks and non https feed sources:

find /Applications ~/Applications /usr -name Sparkle.framework -exec echo {} \; -exec defaults read {}/../../Info.plist SUFeedURL 2>/dev/null \; | grep -vw ^https

You can mdfind kind:app to check for apps outside the three folders I fed into the find command. Also, keep in mind other user home folders if you actually implement this change. Also, for managing several computers, you'll want to push a profile or a better implemented script to parse and disable these apps:

bmike
  • 917
  • 2
  • 22
  • 41
  • On the developer side, I agree that it's a no-brainer to update. You're correct about the intention of my question though -- mainly concerned about apps on our user's computers which were downloaded elsewhere. I wouldn't try to actually run an update with the frankenstein sparkle version; but, as far as mitigating the mitm threat, it seemed rational. The SUFeedURL is a great alternative, though. (although, I know at least one of my apps has that URL embedded in the source code and not accessible via the plist). I'll hold off on my mass 1.13 replacement for now... – Kent Feb 15 '16 at 02:21