How Dropbox Hacks Your Mac

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.

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.

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

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

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.