Sparkle Updater Vulnerability

"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 […]