How Dropbox Hacks Your Mac

(applehelpwriter.com)

1037 points 8bitben | 1 comments | 09 Sep 16 15:52 UTC | HN request time: 0.259s | source

Show context

newhouseb ◴[09 Sep 16 18:15 UTC] No.12464730[source]▶

Hi HN — Ben from Dropbox here on the desktop client team. Wanted to clarify a few things —

- Clearly we need to do a better job communicating about Dropbox’s OS integration. We ask for permissions once but don’t describe what we’re doing or why. We’ll fix that.

- We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.

- We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).

- We use elevated access for where the built-in FS APIs come up short. We've been working with Apple to eliminate this dependency and we should have what we need soon.

- We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

- We check and set privileges on startup — the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. The intent was never to frustrate people or override their choices.

We’re all jumping on this. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused.

replies(30): >>12464748 #>>12464757 #>>12464795 #>>12464842 #>>12464871 #>>12464901 #>>12464973 #>>12464992 #>>12465003 #>>12465065 #>>12465178 #>>12465579 #>>12465584 #>>12465819 #>>12465975 #>>12466068 #>>12466126 #>>12466141 #>>12466143 #>>12466315 #>>12466502 #>>12466626 #>>12466822 #>>12468525 #>>12468769 #>>12468833 #>>12469145 #>>12470515 #>>12473045 #>>12481821 #

zenexer ◴[11 Sep 16 12:26 UTC] No.12473045[source]▶

>>12464730 #

I'm not really concerned about Dropbox's intentions, or even the accessibility integration. What worries me is:

- There are numerous setuid binaries without any documentation or source code available. These have the potential to breed nasty zero-day privilege escalation exploits, possibly worse.

- Dropbox goes out of its way to obfuscate its Python bytecode. This doesn't prevent intellectual property theft: there will always be people capable of reverse engineering it (e.g., https://github.com/rumpeltux/dropboxdec). The only effect that it has is to significantly decrease the security of the application: technical users can't easily review the inner workings without a substantial time investment. Hackers, on the other hand, have massive profits to gain from reverse engineering something as popular as Dropbox, and won't hesitate to do so. This represents a lack of regard for security on Dropbox's part, indicating that they favor intellectual property protection over the security of their customers. When I buy a car, I can open it up, check the brakes, and be sure I'm not going to crash into a tree. I expect to be able to do the same with the software on my computer.

replies(1): >>12473372 #

1. zenexer ◴[11 Sep 16 14:00 UTC] No.12473372[source]▶

>>12473045 #

It looks like DropboxHelperInstaller can be used to extract an arbitrary tarball as root into /Library/DropboxHelperTools, preserving permissions. It takes two arguments: the first is a number (doesn't seem to matter--maybe PPID for callback?) and the second is the bath to the GZIP'd tarball. It seems to require that the tarball have an RSA signature appended to the end, but there are signs that the check may be less than ideal and possible to circumvent.

Output from extracting a Dropbox-signed tarball (in this case, DropboxHelperInstall's own tarball):

    <pid>52229</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    mkdir '/Library/DropboxHelperTools' 0755 -> 17
    extracting ./._DropboxHelperInstaller
    extracting DropboxHelperInstaller
    <ok>

Output from attempt to extract a third-party tarball:

    <pid>52286</pid>
    missing magic number
    unable to read_digest
    couldn't verify signature
    <failure> -1

Output from attempt to extract a third-party tarball with the signature copied from a Dropbox tarball:

    <pid>52142</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    crypto error while Verifying Signature: bad signature (in rsa routines:INT_RSA_VERIFY)
    couldn't verify signature
    <failure> -1

It's probably worth reverse engineering DropboxHelperInstaller to ensure that the signature check can't be evaded. Even then, I'm not sure I like the idea of anyone with Dropbox's private key being able to install arbitrary setuid binaries on my machine. Given recent events, it's quite possible the private key has already been stolen.

↑