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

http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/

by jamsc • 10 years ago

87 42 10 years ago

yoz-y2• 10 years ago

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.

masklinn3• 10 years ago

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)

anon13855• 10 years ago

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.

lucb1e• 10 years ago

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?

derefr2• 10 years ago

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.

anon13855• 10 years ago

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).

gtufano• 10 years ago

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...

pyre• 10 years ago

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.

SyneRyder• 10 years ago

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

EGreg2• 10 years ago

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.

w0utert• 10 years ago

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...

mikeash5• 10 years ago

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?

acdha2• 10 years ago

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.

JohnTHaller• 10 years ago

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.

sjsv• 10 years ago

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.

tushar-r2• 10 years ago

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

ascagnel_• 10 years ago

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

masklinn3• 10 years ago

* 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)

5vforest2• 10 years ago

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

mh-• 10 years ago

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"

blacksmith_tb• 10 years ago

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>

brazzledazzle2• 10 years ago

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.

mikeash5• 10 years ago

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.

brazzledazzle2• 10 years ago

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

cheez• 10 years ago

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

api• 10 years ago

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

joesmo• 10 years ago

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.

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

Related Stories