“Huge” number of Mac apps vulnerable to hijacking, and a fix is elusive | Hacker News Reader

“Huge” number of Mac apps vulnerable to hijacking, and a fix is elusive

arstechnica.com

87 pointsjamsc42 comments

Edit: Sparkle uses signature verification as mikeash pointed out in reply to my comment. I'll leave it because I still agree with my second paragraph but feel free to downvote since it doesn't really contribute much to the topic at hand.

The fact that sparkle renders the feed in a webview is bad, but the reason this is a big issue is because developers aren't using TLS/SSL/https for their update feed URLs. Even if Sparkle is fixed in the app itself your list of binaries can still be hijacked. It always could and always will.

It's 2016, every developer needs to take this seriously. Just because it's a pain in the ass to install an SSL certificate on a web server doesn't mean you can just skip it.

How can they be hijacked if Sparkle is fixed?

Sparkle already uses digital signatures for the updates themselves. That's why everybody thought using HTTP was safe. The problem arose when it turned out that the feed itself, which is not signed, can be used to execute arbitrary code.

Merely using HTTPS is a vast improvement, but it still means that anybody who manages to e.g. take over your server can then cause all of your users to execute arbitrary code. With good key management this is not possible with a fixed Sparkle, since the only code being executed is in the updated app, and the updated app is signed with a key which you should be keeping offline.

Ah, I didn't realize it used signature verification. Nice. I edited my comment. Thanks for taking the time to cure my ignorance.

Sure thing. For whatever it's worth I totally agree that everybody needs to quit screwing around and enable TLS, like, yesterday if they haven't already.

Thanks for the TL;DR. I use TLS! And FWIW, it's really cheap to host downloads with Cloudfront which supports TLS.

I feel a bit of schaudenfreude toward these apps, many of whom fit fully within the sandboxing constraints of the Mac App Store, yet don't bother with it. I much prefer the MAS model, where apps are updated from the MAS app itself (as in any package manager.) Amusing that it has (de-facto) security advantages as well.

The MAS model means you are getting crippled applications with vastly reduced capability. The article talks about things like uTorrent and VLC. These kinds of apps are impossible in the MAS.

MAS apps can also stop running at any time if the DRM checks suddenly fail (e.g. if a certificate expires).

uTorrent and VLC could definitely be MAS apps... the limitation of MAS are not significant for uTorrent or VLC. Application that need elevated privileges, or that needs to access/"pilot" other apps or needs to write everywhere in the filesystem (without user selecting the directory) are...

I don't think any of those apply to VLC or uTorrent... The main problem of MAS (for app that don't need what above) is the app store app in itself (it's garbage) and the review time (that hit back anytime you need to patch something fast)... otherwise the model it's not bad per se...

VLC does all sorts of things that are prohibited by the MAS. For a start you wouldn't be able to open a video file and have VLC automatically pick up an adjacent subtitles file.

A lead VLC dev listed a bunch of the issues here: https://news.ycombinator.com/item?id=7039737

I agree about the store app itself being awful

Even for a simple text editor, AFAIK you can't continually monitor a directory for changes (FSEvents), so it's hopeless.

How does Xcode work to manage its unadorned project folders, anyway? (I mean, I know it offers you that component that elevates and escapes the sandbox and sprays stuff into /Developer, but Xcode still works if you decline to install that.)

Setting Xcode aside, though, the idiomatic "modern OSX" model seems to be one where GUI apps have to own all the files they interact with, usually clumping them together into media-typed document bundle folders. (Xcode's mechanism wouldn't be nearly as inexplicable if the rest of the files lived inside the .xcodeproj.)

An idiomatic OSX text editor app would thus, naively, probably have to be quite crippled: the GUI app would have to simply copy your repo into a project document, and make all its edits in there. No ability to watch for git-initiated changes to the source dir or anything.

But I think there is still a way to idiomatically support the Unix philosophy of "small components, working together against shared files" in modern OSX. You just can't rely solely on GUI apps to enable it. Instead, you need a separate CLI component that "lives in" the un-sandboxed Unix world to be the manager of the Unix-style integration.

Imagine the text editor working on its project bundle, and then a separate CLI component sitting there and just monitoring both the project bundle, and the git working directory—and bidirectionally syncing between them. The sandboxed app still gets to be a sandboxed app, and "works" on its own when the component isn't installed. The component—brought in from outside the MAS, maybe through e.g. Homebrew—just makes extra magic happen.

I'm unsure why more MAS apps aren't designed like this, honestly. It's perfectly sensible for Development apps, at the very least; we all install Homebrew anyway.

Xcode doesn't follow the rules that 3rd party apps must follow. It's not possible for a 3rd party to distribute an app like Xcode through the app store.

Technical limitations aside, uTorrent can never be a MAS app because Apple would never approve it.

The parent was speaking of software that does fit within the MAS model. It seems disingenuous to start talking about software that doesn't as a counterpoint.

OP said "these apps" in reply to an article that mostly talks about apps that aren't possible (or would become extremely clumsy to use) through the MAS (VLC[0], uTorrent[1], Hopper, Sequel Pro, Sketch[1])

A lot of apps violate the MAS limitations in ways people don't realise. There are people in this thread claiming that VLC would fit within the MAS model even though it can't (at least not without ditching a lot of features).

Even if an app fits inside the limitations today, it may not in the future, and migrating away from the MAS is a huge hassle. It's also possible for the limitations to change so apps that are allowed now may not be in the future meaning those apps can't be updated at all, which is something that has already happened.

[0] https://news.ycombinator.com/item?id=7039737

[1] as far as I know torrent apps are banned from the store

[2] http://blog.sketchapp.com/post/134322691555/leaving-the-mac-...

You're correct about MAS apps stopping when the certificate expires. Several of my purchased MAS apps were broken to the point of being unusable when Apple's MAS certificate expired [1]. It happened in mid November 2015, but Apple didn't completely fix it until the end of January 2016 [2].

[1] http://www.macrumors.com/2015/11/12/mac-app-store-apps-damag...

[2] https://support.apple.com/en-au/HT205702

You're right. When we found out the potential for this we removed all the checks and our apps are effectively free to download. We only make money through in-app purchases and advertising. it would be a piss-poor user experience if the app would suddenly crash upon launch because some certificate expired.

But aren't you still using the certificate to validate the receipt to find out which in-app purchases have been made?

If so, wouldn't you have to validate receipts against a new certificate once the old one expires?

Once the receipts for in-app purchases are validated, they don't need to be validated again every time. It's true that people wouldn't be able to make new in-app purchases (unless we have another payment processor as a backup). But at least their app will WORK! And we'll be able to communicate to them how to refresh the certificate and be able to make in-app purchases.

I agree to the extent that I'd also very much prefer if all apps that fit the security model of the mac app store would be distributed through it, I hate it that almost every program on my machine seems to have its own way of updating itself (not to mention the initial download/install).

I do think Apple really is to blame here though, the MAS is frankly a big pile of junk, for users, but in particular for developers. It looks like they just launched it and called it a day, the interface is slow, clunky, it doesn't work properly if you have multiple accounts (and there's no way to merge them), updates often fail to download, searching is a mess etc. This is all just user-level complaints, apparently for developers things are even worse if you read around. Over the last year or two almost any app I initially installed through the MAS appears to have moved away from it...

I feel the opposite. Some of the blame here can be placed with Apple and their idiotic handling of the App Store. If the App Store wasn't such a shitty place to sell apps, many of these app could have been there and used Apple's presumably-secure update mechanism rather than rolling their own. What good are security benefits if you can't make money selling your product there?

This matches everything I've read from Mac developers – the App Store would be a great idea except for the arbitrary impediments to having a viable business.

Michael Tsai had a good roundup of just how widespread that trend's becoming and how it's driven by only a few issues like the inability to do paid upgrades and the slow review process:

http://mjtsai.com/blog/2015/12/01/sketch-leaving-the-mac-app...

I really wish the Mac App Store was more like Yum/APT where you have a single update mechanism with baked-in mandatory security but otherwise leave publishing up to the actual developers. If Apple wants to have a curated store with reviews, etc. that's fine but it's just not viable as the only option for every class of application.

There's some additional irony in that apps can be sandboxed even when distributed outside the App Store, and many of these apps could function fine within the sandbox... except for Sparkle, which needs more access!

And there's no particular reason everything in the App Store must be sandboxed. It used to not be required, then Apple changed the rules. Sandboxing helps with security, but for this particular question of a vulnerable app updater, simply using the App Store's update mechanism would suffice to make it safe, even for non-sandboxed apps.

I wish they had a two-tier approach: have the current reviewed thing as a sort of Apple-preferred gold star kind of deal but allow other apps to be listed relying on customer reviews, and maybe some sort of warning that this hasn't been audited as much, etc.

Besides the reliable updater, it'd be really nice just for them to be able to flip the kill-switch on known-exploitable apps ASAP when something bad happens.

Unfortunately, the Mac App Store has other major issues that prevent publishers and users from using it. While sandboxing can prevent security issues like this, it also interferes with basic functionality of many apps like IDEs that use multiple files. Even VLC can't automatically open the associated subtitles file for a video you open. So, there are whole categories of apps that are a bad fit as they'll be hobbled in terms of user experience/functionality. Add to that the 30% take for Apple that cuts into the bottom line and isn't made up for by increased installs from the store, the inability to charge for new versions of apps which kills off long-term development funding, and the poor UI and bugginess of the store itself and it's clear why the vast majority developers don't use the Mac App Store and existing high-profile developers in the store have been exiting from it.

I blame Apple. Their failure to bring a proper package manager to OS X is the reason this type of software exists and needs to be added ad hoc in each application, often insecurely. Hell, even Windows has a package manager now. It's just ridiculous how little Apple cares about OS X these days. And no, the App Store is not a package manager though the rare app is available there. Then again, the more I think about this, the more I realize it's pointless to even hope for such things in OS X given Apple's hostility toward developers.

Interestingly enough, _none_ of the applications I have installed uses the latest Sparkle version and most use versions as old as 1.5 or 1.6. Many do not use https. This will be painfully long to fix.

I do have adium on the latest release (1.13.1), but aside from that I see the same thing, here's a summary of the Sparkle CFBundleShortVersionString on my system (dates added by myself):

     9 	1.5 Beta
     2 	1.5 Beta 5
    12 	1.5 Beta 6
     1 	1.5
     1 	1.6
     3 	1.8.0
     1 	1.9.0
     2 	1.10.0
     1 	1.12.0
     1 	1.13.1

However note that Sparkle 1.5 isn't even compatible with El Cap, I expect a number of these are in software I haven't launched in years and have just been carrying from migration to migration, the up-to-date software may be using an up-to-date sparkle.

Or not.

Probably not though, considering Acorn 5.2.1 (released in December 2015, the same day as Sparkle 1.12.0) uses Sparkle 1.9.0 (released in January 2015)

Sparkle dropped support for OS X 10.6 at some point, so that's probably a reason for some apps continuing to use older versions.

That's a good point, but 10.6 support was dropped in 1.7.0 so technically the 1.5s should be able to run 1.6.1.

Also I undercounted the number of old versions, turns out ancient sparkles didn't have a CFBundleShortVersionString in their plist and I also have a bunch of Sparkle 1.0 and 1.1 lying around.

interesting command from one of the comments on the original article:

find /Applications -path '*Autoupdate.app/Contents/Info.plist' -exec echo {} \; -exec grep -A1 CFBundleShortVersionString '{}' \; | grep -v CFBundleShortVersionString

This gives an overview of the programs using sparkle, and which version.

If you use homebrew, replace /Applications with /opt.

Why would a Homebrew app use Sparkle? Homebrew is a package manager, so updates would be under its purview.

Some applications (probably those that are also distributed outside Homebrew) do contain the Sparkle framework (which may or may not be disabled).

As an example, in my case this concerns MacVim (on one computer only though)

Edit: maybe this is somehow tied to Cask?

On my machine it is only cask.

* a better way to read the CFBundleShortVersionString would be to use `defaults`: replace the exec grep; grep -v by exec `defaults read '{}' CFBundleShortVersionString`

* there are applications which use the Sparkle framework but not the Autoupdate app, and apparently applications which contain Autoupdate.app but it doesn't have a CFBundleShortVersionString. On my machine, 43 application bundles contain Sparkle, 10 have an Autoupdate.app and 9 have an Autoupdate.app with a CFBundleShortVersionString plist key. Reading Sparkle.framework/Versions/A/Resources/Info.plist would be more reliable, but even that is not perfect, some of those don't have a CFBundleShortVersionString, only a CFBundleVersion (those are most likely the downright ancient Sparkle versions, we're talking 1.0 and 1.1)

Augmented it with a bit of Ruby in order to find the "SUFeedURL", which if using the `http` protocol, means that an application is vulnerable.

https://gist.github.com/ajb/876107d0edc0f2c11779

FYI, it can be stored in theoretically any key. But it's probably worth looking for SUFeedURL* at least.

  % plutil -p /Applications/iTerm.app/Contents/Info.plist| grep SUFeedURL
  "SUFeedURLForFinal" => "https://iterm2.com/appcasts/final.xml"
  "SUFeedURLForTesting" => "https://iterm2.com/appcasts/testing3.xml"

Good info! I really have no clue what I'm doing. Just trying to help coworkers figure out if they need to uninstall any apps, really :)

Mostly no surprises for me, but Xquartz is using 1.6!

/Applications/Utilities/XQuartz.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/Autoupdate.app/Contents/Info.plist <string>1.6</string>

It sounds a bit weird, not sure I understand everything. How hard is it to update a dependency and run a web server with https to serve new versions?

We built our auto-updated to use its own signatures in addition to https and Mac app signing because we don't trust CAs.

Reply on news.ycombinator.com