Sparkle is an open source update framework that is used within thousands of Mac apps, including my own AutoCasperNBI & AutoImagrNBI.
A vulnerability within which was recently disclosed, with an update to Sparkle issued soon after.
However, the update may take some time to reach all the apps that are on the Macs that we admin. So the below is some more detail, methods of mitigation & detection.
For details on the vulnerability please read the original post disclosing it here & another example here.
As mentioned, there is an update to Sparkle which will close this vulnerability. However, not all app developers may be quick to the mark to resolve by either:
- Updating the apps Sparkle framework to 1.13.1.
- Move their apps Software Update Feed URL (SUFeedURL) from http:// to https://.
The latter is what the developers should have done.
Heck this little blog is https because of Sparkle & it’s update framework being used in AutoCasperNBI & AutoImagrNBI, with their respective SUFeedURL pointing here.
Mitigating The Risk
As admins there are a few things we can to to mitigate the risk of a MITM attack from one of these apps affecting Macs that we manage.
Many apps have auto update features. Often these can be turned off & I’d advise they are for apps used across your Macs. At least until the apps have been updated.
Greg Neagle has a number of examples here which might help for starters.
UPDATE: Allister Banks has written a script to create configuration profiles like those linked above for applications that include the Sparkle framework.
With updates disabled client side, we can pull the updates via AutoPKG to deploy to our Macs.
Even if not currently managing updating applications via AutoPKG, i’d advise you add the recipes for those applications found in the script at then end of this post, so you can push out the patched versions of the applications once released.
Admin vs Non-Admin
Sparkle can update apps that live in any location on your Macs.
If your users are not admins then they risk is reduced, but they may still be caught by this vulnerability with anything malicious being limited to their account unless the exploit then manages somehow to escalate privileges further.
There are a few methods to detect apps using Sparkle that are vulnerable to MITM.
A few folks in the #autopkg channel on macadmins.org Slack have been scraping the SUFeedURL’s from within AutoPKG recipes & other sources & then reaching out to the developers.
Hello @Adium! In light of recent vuln (https://t.co/p9VTYNBdmz), will you switch to using HTTPS for your app's SUFeedURL? Thanks!— Elliot Jordan (@homebysix) January 30, 2016
However, the developer would need to push out an update with the https SUFeedURL in the applications info.plist for the application to see the change as well as https whatever site they host the update XML on. So this will need one more update for them to make the change.
Also, if you maintain any AutoPKG recipes, you may need to change the URLs to https once the developer has made the change themselves.
The other option is that the developers update their applications with the newer Sparkle update framework that has this vulnerability patched, this would not reflect in the applications SUFeedURL so the above could lead to false positives, & again requires the application to be updated.
(Thanks to Allister for pointing this out).
The SUFeedURL points an applications Sparkle framework to an XML file (referred to as the AppCast.xml), within which a few details can be found.
Below is a cut down example of AutoCasperNBI’s AppCast.xml:
Within the second set <description> tags are the release notes. This is an example of safe release notes as they are within the AppCast.xml & are only available over https.
The below is taken from another application. Within the <sparkle:releaseNotesLink> tags there is a http link.
The above should be easily remedied as the link can be changed to https within the AppCast.xml without updating the application.
Sadly, it’s not that easy to detect without downloading an applications AppCast.xml & then verifying that the release notes are not within the AppCast.xml & are instead linked to a http source.
If you find a link like the above, please contact the developer.
There have been a few command line methods to detect is an application is potentially vulnerable, such as:
However, these can be be quite wasteful (as pointed out by @Allister on macadmins.org Slack) & whilst they would get any applications with an SUFeedURL that is http://, I didn’t see many command line methods that would also check the version of the Sparkle framework included within the application to check to see if that had been updated & therefore patched the vulnerability.
With the above issue of checking both the applications info.plist for the SUFeedURL & the applications bundled Sparkle frameworks version, I came up with the below script.
This is is intended to be used as an Extension Attribute, but could be used in other ways, & will return a list of all vulnerable apps on the Macs it’s run on.
If running via as an Extension attribute, you should get a list of applications with their paths that are vulnerable, as well as their bundle ID’s for generating profiles to block their updates via Extinguish.
[github file = “/macmule/JSS-Extension-Attributes/blob/master/Sparkle-MITM-Vuln-Apps.py”]
Thanks to the number of Mac Admins whom tweeted or posted about this on the macadmins.org Slack.
As well as @Bruienne for the Python pointers & @Allister for looking further into the issue, rewriting my EA & writing Extinguish to help create profiles to block application updates.
One thought on “Sparkle Updater Framework HTTP man-in-the-middle vulnerability”