Is it safe to replace Sparkle with a newer version

Question

&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.

Answer 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:

• https://macmule.com/2016/01/31/sparkle-updater-framework-http-man-in-the-middle-vulnerability/
• https://github.com/arubdesu/extinguish