The Sparkle project coordinators have already released an update that disables vectors under their control, although they still exist in OS X—they’re just much harder to take advantage of without Sparkle providing a pathway. App developers who still use http for Sparkle connections need to update their software and release new versions immediately with https, and ultimately (and soonish) incorporate the newest Sparkle release.
This free, open-source code module was initially created by a single developer in 2006 (now handed off to a team) as a way to allow in-app updates of software that had the ease of app stores: Instead of having to check on updates or be on a mailing list about them, and then download new releases from a website and run an installer, Sparkle automated all that within the program. Apps could offer preferences to let apps routinely check for updates automatically (as well as have a manual Check for Updates option). The Sparkle framework checks an XML-based update feed that’s hosted at the app developer’s site, and whenever a release number appears higher than the current version, notifies a user with release notes, and allows a one-click operation to download, quit the app, install the update, and relaunch.
Researcher Radosław Karpowicz (who goes by Radek) discovered two separate vulnerabilities. The first is that developers using Sparkle with http instead of https allow a man-in-the-middle (MitM) attack that would allow a malicious party to redirect the request without detection, unlike with https. This can happen on a public Wi-Fi network, business networks that lack good internal controls, and at higher-level Internet hubs when malicious parties gain access or governments demand it or control them. MitM for unencrypted connections just requires a position where traffic can be examined and substituted.
Ars Technica notes that some automated methods to take advantage of this vulnerability have already appeared. While this is an extremely serious exploit, and may have ramifications beyond Sparkle, it’s at least easily and quickly patched by developers. It also requires that an attacker target specific apps or app versions that remain vulnerable, and have access to privileged network positions if they want to exploit en masse—as opposed to thin pickings on a local Wi-Fi network they have to set up shop on in physical proximity.
Because many, many apps distributed directly by developers use Sparkle, and there’s no easy way to know which haven’t updated to https and the newest Sparkle code, your best bet is to disable automatic updates in all your software, and perform manual checks only on trusted home or work networks. You can also visit websites directly to look for updates that contain patched code, as with Sequel Pro and VLC, two affected apps that are now up to date.
Apple needs to make a number of minor changes in OS X to prevent exploiting the broader vulnerabilities found by Karpowicz and others, but these Sparkle fixes shut down the most likely avenues of exploitation.
This situation re-emphasizes something I’ve written about several times—just a few weeks ago, most recently—after years of warnings from companies as large and pervasive as Google down to individual security researchers: http shouldn’t be used for any purpose because it can be so easily hijacked, allowing other attacks to take place that would be otherwise blocked or minimized.