How Dropbox Hacks Your Mac

Non-clickbait title: "How Dropbox uses the root access that you give it during installation to give itself Accessibility authorization without triggering the usual popup".

Great summary. But it's still some kind of hack.

If every app I installed did this then my mac is closer to getting hacked.

Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.

How's that any different compared to Linux? AFAIK apt packages can run arbitrary scripts as root.

> Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.

You don't need root to do any of those things. If you're going to run the SSH server on port 22, sure, but it can be run on any port above 1024 by a regular user in user space.

If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.

Think a NAT is going to save you? A malicious program can SSH out and create a reverse tunnel to circumvent it.

Short answer: running anything you don't know or trust is dangerous, root access just makes it more dangerous.

Linux packages come from the distribution and are controlled by the distribution, not some random 3rd party business.

It's slightly different, because Dropbox board members support warrantless surveillance: http://www.drop-dropbox.com/

There's a world of difference, as long as you are using only default repositories (which you should). Apt itself is root, of course, but it is (or should be) trustworthy. All other apps never see root access unless they need it - and if it is needed, then the package maintainer has checked the package to make sure it only uses root when necessary. Kind of like Apple checking apps on AppStore.

That skips the important point that it's not supposed to be possible for even root to do this without a prompt.

This is not the main difference (which is that apt packages are checked by package maintainers), but thanks for sharing the link, didn't know that. It makes this hack even more serious.

"Accessibility authorization" sounds benign, but the "authorization" it gives itself is full control of the Mac via the Accessibility API.

So, "How Dropbox uses the root access you give it during installation to gain full control of your Mac without triggering the usual popup."

>If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.

That file is -rw-r--r--, so only the owner or root can change it, unless I am misunderstanding you?

That app is running as you, so it is the owner of the file at that point.

No respectable package would put up a fake sudo prompt only to stash away your password for later use.

Not exactly. If you remove dropbox from the accessibility auth list while the client is still running (without removing /Library/DropboxHelperTools) it just adds itself back in. Also it prompts for the password after installation.

So it's more like "how dropbox uses the root access you give it after installation to install software which will permanently re-add itself to accessibility even if you attempt remove its authorization".

Corrected proposed non-clickbait title: "How Dropbox fakes an authorization prompt to trick you into entering credentials that it then caches in order to bypass restrictions on what root is able to do so that it can persist a security bypass mechanism."

The first bit, for me, is key.

It doesn't do that. It doesn't cache the credentials. It doesn't even see your password.

How is it adding itself back to the list after being removed, then?

(Not disbelieving you at all, I just haven't understood this part.)

toomim is correct. Upon reading the update, it looks like it pops an OS X auth dialog to update a file (TCC.db) which is used to bypass the normal restrictions on what the root user is able to do. This bypass is used to manipulate the AX config.

Slimy, slimy, slimy.

It adds a suid binary to /Library/DropboxHelperTools. This binary executes as root's effective user ID no matter who executes it and adds Dropbox to the accessibility list.

Dropbox doesn't save your password.

...But I am wondering why one of these suid binaries is world-writable.

It's a good thing Dropbox isn't doing that, then.

Lots of people getting mad at Dropbox for this, which is fine, but should we not also get mad at Apple for making their "security" system so easy to circumvent?

Being an app developer that was bitten in the ass by the new "security" in El Crapitan, and having spent 2 weeks trying to get our app back to normal, this makes me really mad that Apple makes us developers jump through all these hoops for security that isn't actually secure anyway.

ah, it turns out none of the binaries is world-writable in a default installation. My mistake.

No, it's not that the point. The point is that they somehow store your sudo password to set again the accessibility permission at every login. I honestly don't see why the title should be considered a click-bait, it looks pretty much very accurate to me.

Then please explain how it manages to set the accessibility privilege at every login after the user explicitly revokes it. I can see only two options:

1) the Dropbox client stores the password and uses it to hack the accesses db at every login.

2) the Dropbox client runs as root and does the same thing.

Both options are simply terrible from a security point of view

Not sure if this is how they do it, but OS X has another option (which is in fact recommended by Apple for all tasks needing elevated permissions): installation of a privileged helper tool.[1] The helper tool communicates with the main app via IPC, ideally such that the only things the app can ask are precisely the things it's supposed to do (e.g. the helper will only sneak in accessibility for the dropbox app, and nobody else). The helper tool removes a lot of the surface area for security holes, assuming the IPC protocol is well written (not something like "here's this string, run it as a shell command with root privileges).

[1]: https://developer.apple.com/library/mac/documentation/Securi...

3) Dropbox installs some helper programs with the SUID bit set.

And this is what they actually do.

    % ls -l /Library/DropboxHelperTools/Dropbox_u501
    total 256
    -r-s--x--x  1 root  wheel    9632 Sep  8 20:10 dbaccessperm
    -r-s--x--x  1 root  wheel  116668 Sep  8 20:10 dbfseventsd

(Note the SUID bit and the root owner, meaning that these binaries will run with the root UID when started by a normal user.)

You're absolutely right.