Tuesday, February 2, 2016 [Tweets] [Favorites]

Sparkle Updater Vulnerability

Radek:

Let’s sum up everything to that point:

  • AppCast process is using HTTP that could be intercepted and modified on the fly
  • We can insert our HTML and JavaScript code into a WebView component to display it to the user
  • We control the transmission after doing the MITM attack

[…]

The vulnerability is not in code signing itself. It exists due to the functionality provided by the WebKit view that allows JavaScript execution and the ability to modify unencrypted HTTP traffic (XML response).

He uses JavaScript and the fact that the Finder is the default FTP handler to mount a .terminal file at a known location. JavaScript then opens the .terminal file via a “file://” URL, executing arbitrary code. I was surprised that this second part is possible. This seems like more of a WebKit vulnerability.

Radek:

This attack works on stock Mac OS X install, and GateKeeper enabled with both options “Mac App Store and identified developers” or “Mac App Store” (the strictest one).

Simone Margaritelli (via Greg Slepak):

I’m not going to explain the details of his attack, his post is quite self explanatory, but I’ll show you how easy it is to mass pwn OSX machines on your network using the new OSX Sparkle bettercap proxy module.

Moreover, I improved the attack ... Radek shown how to get RCE using an OSX terminal profile file, I will show you how to make the target execute any Mach-O executable you want!

My apps use HTTPS for software update checks, using my own code rather than Sparkle, and JavaScript is disabled.

Update (2016-02-02): Rosyna Keller:

That is, Sparkle was explicitly opening every file using LaunchServices by overriding the default WebView handler.

Update (2016-02-10): Dan Goodin:

Fellow researcher Simone Margaritelli has developed a technique that streamlines the attack by allowing it to work with the Metasploit exploit framework. He showed how he could exploit the vulnerability on a fully patched Mac running the latest version of the VLC Media Player. VLC developers released an update three days ago that patches the vulnerability so that the attack no longer works against the latest version.

[…]

The precise number of apps affected isn’t known because it’s not easy to detect all the conditions necessary for them to be vulnerable. Radek estimated the number to be "huge" and said he has confirmed that the list includes Camtasia 2 v2.10.4, DuetDisplay v1.5.2.4, uTorrent v1.8.7, and Sketch v3.5.1. Computer forensics expert Jonathan Zdziarski told Ars that the Hopper reverse engineering tool and DXO Optics Pro are also susceptible. A longer list of apps that rely on Sparkle is here, but readers are cautioned that not all of them communicate over insecure HTTP channels or use a vulnerable version of the update framework. Margaritelli said the most recent version of the Adium instant messenger uses HTTPS for updates and isn’t vulnerable.

Juli Clover:

Sparkle has released a fix in the newest version of the Sparkle Updater, but it will take some time for Mac apps to implement the patched framework.

Update (2016-02-16): Josh Centers:

If you are still worried, how do you figure out which apps are vulnerable? People have offered all sorts of Terminal commands to suss out vulnerable apps, but the best one I’ve found comes from RussW, a commenter on Mac Kung Fu. His solution checks to see if the app uses both Sparkle and an insecure HTTP connection, and then it prints out a list of those apps in a fairly readable format.

Unfortunately, there are smart quotes in RussW’s text that partially break the command (thanks to reader Joe for pointing that out), so I’ve created a Pastebin link with the properly formatted command. Follow that link, copy the command under RAW Paste Data, paste the command in the Terminal window, and press Return. Terminal will list the vulnerable apps in your Applications folder.

10 Comments

"He uses JavaScript and the fact that the Finder is the default FTP handler to mount a .terminal file at a known location. JavaScript then opens the .terminal file via a “file://” URL, executing arbitrary code."

Huh. I learn something new every day. But it's not every day I learn something really f*cking important. For the past 10+ years, I've thought "arbitrary code execution" meant that an attacker could execute only random code. In other words, I thought it meant an attacker could crash a process, or crash the OS, but not pwn you. Boy, was I ever wrong. Time to re-evaluate all my security measures.

-----

"JavaScript then opens the .terminal file via a “file://” URL, executing arbitrary code. I was surprised that this second part is possible. This seems like more of a WebKit vulnerability."

This baffles me even utterly. I was under the impression the “file://” LaunchServices scheme hole was fixed at the OS level a long time ago. That's why folks like me had to write custom AppleScript process handlers to get things outside the browser like .inetloc files and links in text documents to open files.

So, under my understanding, the WebKit issue shouldn't matter, since the problem was fixed at the OS level. I wonder what I'm missing.

@Chucky Not random, especially before Address Space Layout Randomization.

Please see the update above. Rosyna Keller identified (since Sparkle is open source) the code where it was overriding WebKit’s default URL handler to make the app open files via Launch Services.

"Please see the update above. Rosyna Keller identified (since Sparkle is open source) the code where it was overriding WebKit’s default URL handler to make the app open files via Launch Services."

Look, this may all be far above my technical level, so you don't need to bother educating me from scratch if I'm just not going to get it. (I did read the Rosyna thread, but it didn't help me.)

But my confusion stems from that if whatever WebKit is doing indeed involves the “file://” LaunchServices scheme, I thought that was closed at the OS level, not at the browser or WebKit level. Hence why I brought up the customer AppleScript handlers folks had to write in response. Now maybe Rosyna is saying that “file://” isn't involved after all. Or maybe WebKit has special entitlements from the OS that nothing else has to execute “file://”. I dunno. All above my pay grade.

And again, feel free to ignore me if I'm missing something at a level that's too much hassle to explain.

@Chucky I’m not exactly sure which closure you are referring to. My understanding is that when WebKit sees the “file://” URL, it asks the app (via a delegate method) what to do with it. The default is to ignore it, but Sparkle overrides that to open it using Launch Services. Secondly, most files that are downloaded will be quarantined so that opening them via Launch Services will show a dialog warning the user and telling where the file was downloaded from. However, the downloading app must specifically add the files to the quarantine. Sparkle sensibly doesn’t quarantine its own updates. And, more relevant in this example, the Finder is what’s downloading/mounting from the “ftp://” URL, but it’s not using the quarantine.

I already got the issue with the Quarantine. I already got the issue with the Finder and “ftp://”.

"I’m not exactly sure which closure you are referring to."

Back around '04/'05, there was a recognition of URI exploits that led to RCDefaultApp being written. My memory is that Apple first tried patching individual apps, like Help Viewer, and then finally fixed the problem at the OS level. That's why custom AppleScript handlers are needed if you want to replace the utility of "file://" from .inetloc files or links in text documents. My memory could very well be wrong.

"My understanding is that when WebKit sees the “file://” URL, it asks the app (via a delegate method) what to do with it. The default is to ignore it, but Sparkle overrides that to open it using Launch Services."

This is the part I don't grok. As noted, I thought the OS fix made all attempts to exploit “file://” via LaunchServices impossible.

But we can leave it here. I do appreciate your attempts to explain it to me. I think it's just above my pay grade.

@Chucky I don’t recall that history. I thought RCDefaultApp was written primarily to change the default handlers rather than turn them off.

It’s not clear to me how a fix could do what you’re suggesting given that the Finder has made the file available at a particular location, with no quarantine. At that point, the fact that there was a “file://” URL is kind of irrelevant. The file exists, and the app tells the system to open it, and there is no reason for the system not to comply. Perhaps someone else can fill us in on exactly what was fixed.

"I don’t recall that history. I thought RCDefaultApp was written primarily to change the default handlers rather than turn them off."

Correct you are. I guess that it's just that I personally discovered RCDefaultApp at the time of the first exploits through info like this. Previously, I'd been using an alternative method.

"It’s not clear to me how a fix could do what you’re suggesting given that the Finder has made the file available at a particular location, with no quarantine. At that point, the fact that there was a “file://” URL is kind of irrelevant. The file exists, and the app tells the system to open it, and there is no reason for the system not to comply."

OK. But that's why I keep coming back to the issue of being forced to write a custom AppleScript handler if you want to replicate the utility of "file://" from .inetloc files or links in text documents.

There was a long period in time when you didn't have to do that. A "file://" URL used to let you open up a file just fine; no custom AppleScript handler needed. And then it didn't. I'm pretty close to certain the change took place in relatively close proximity after the first exploits, after Apple first tried the tack of patching individual apps like Help Viewer.

So perhaps I mistakenly extrapolated that the "file://" prohibition was system-wide, when it was only done to certain elements of the system? I dunno. But do you see what I'm getting at in general?

(I'm not confused about this exploit in general. I'm solely confused about how it's able to leverage "file://" to do its work.)

But that's why I keep coming back to the issue of being forced to write a custom AppleScript handler if you want to replicate the utility of "file://" from .inetloc files or links in text documents.

I’m not familiar with that at all. Could you give an example? I just pasted a file:// URL into OmniFocus, then told it to Open URL, and it did open the file.

"I’m not familiar with that at all. Could you give an example? I just pasted a file:// URL into OmniFocus, then told it to Open URL, and it did open the file."

Just tried that. And it worked. Now I'm baffled about what the hell I'm talking about. And why in god's name do I have an AppleScript scheme handler in the first place.

If I figure it out, I'll report back. If not, I'm extremely sorry for wasting your time, and I should probably get myself checked out for very early dementia.

(I do think I was talking about something sensible, but I need to track down exactly what the hell it was.)

[…] wondered what it would be like if third-party developers didn’t have to use frameworks like Sparkle and could instead pipe their updates through Apple’s official software update […]

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment