How updating your Mac’s apps could allow man-in-the-middle attacks

The drumbeat of avoiding insecure “http” web connections beats every louder. A researcher disclosed several days ago a vulnerability hiding in plain sight with the Sparkle update framework for OS X Yosemite and El Capitan. Because Sparkle allows apps to update via non-encrypted web connections, the potential of sending malicious updates through man-in-the-middle attacks is quite high. But the attack works because of three separate OS X issues: executing JavaScript in WebKit views intended to show formatted text; mounting FTP servers on the desktop; and Gatekeeper not checking certain paths for and kinds of downloaded files. (Ars Technica reported first on the researcher’s post, which went up in late January.)

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.

Karpowicz notes that an attacker could provide an alternate XML update file in response to a Sparkle check. That suborned response not only could show false information and lead people to install malware, but it can also take advantage of a second vulnerability that’s part of OS X’s WebKit, which Sparkle uses to display formatted update information in a pop-up window in an app. The XML file’s update payload can include JavaScript that’s directly executed in that WebKit window, opening a browser and running code that could open a webpage that has zero-day malware—exploits that haven’t been patched yet.

But the worse attack is having the JavaScript connect to an FTP (File Transfer Protocol) server, which OS X mounts on the desktop as a volume. The JavaScript can then execute a terminal script, in one example, which in turn runs command-line functions. (Apparently, if you’ve ever launched Firefox on your Mac, this avenue is disabled.)

This could all happen without a user being present or clicking anything. All it requires is an OS X app that uses Sparkle and http having its feed hijacked so that on the next automatic check for updates, the feed data is downloaded and the update message appears. That triggers JavaScript execution. Gatekeeper isn’t triggered, because the downloaded file doesn’t meet the test for a downloaded app that’s checked for a developer signature. Karpowicz documented a few other malicious activities that could crash OS X or cause other problems.

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.