
“Huge” number of Mac apps vulnerable to hijacking, and a fix is elusive - jamsc
http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
======
brazzledazzle
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.

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

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

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

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

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

~~~
anon1385
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](https://news.ycombinator.com/item?id=7039737)

I agree about the store app itself being awful

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

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

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

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

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

~~~
masklinn
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)

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

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

------
sjsv
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-r
If you use homebrew, replace /Applications with /opt.

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

~~~
yoz-y
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?

~~~
tushar-r
On my machine it is only cask.

------
lucb1e
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?

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

