Live data from Hacker News

How Dropbox Hacks Your Mac

applehelpwriter.com

411–420 of 435 posts

Re: How Dropbox Hacks Your Mac

#411

Earlier quoted context omitted.

Doesn't Apple literally have a sync solution on this platform, likely using these same APIs? FSEvents powers a lot of core functionality on macOS so it's surprising to hear it just doesn't meet Dropboxes needs. It's cool they are moving into the kernel soon anyway, just install their kext...

I can't fathom why you think them being a kext is a good thing. I refuse to use anything anymore that needs that, every app that needs that inevitably is a source of something breaking in OS X

Was complete sarcasm

Re: How Dropbox Hacks Your Mac

#412
post #290

Earlier quoted context omitted.

I'd love to hear what you find. My research has shown that Dropbox is mostly the only sync service supported in mobile apps. iCloud is next. After that it's very rare to see any other integration. I'd love to see Box or someone else encourage popular apps to support their sync platforms, but I doubt it will happen. I blame Apple for not supporting easy 3rd party integrations.

Seafile ( https://www.seafile.com ) and ownCloud ( https://owncloud.org ) both are open source and have mobile apps. Worth checking!

box.com as well. We have free accounts, hipaa/gov grade encryption and security, and lots of collaboration options. :)

Re: How Dropbox Hacks Your Mac

#413

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…

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.

Re: How Dropbox Hacks Your Mac

#414

Earlier quoted context omitted.

AMP is not the solution. Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place. And, using AMP itself adds bloat[1]. I couldn’t even read the author’s AMP version without enabling JavaScript. [1] https://www.ampproject.org/docs/get_started/create/basic_mar...

> just not add bloat to HTML pages This isn't really a solution when many authors use a CMS, like WordPress and others, where the bloat is built-in. Sure you can write a custom theme etc, but not everyone (1) has the ability to do that, and (2) wants to dedicate the time to do that.

Creating AMP pages requires just as much ability and time.

Re: How Dropbox Hacks Your Mac

#415

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…

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 wil…

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

    52229
    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
    
Output from attempt to extract a third-party tarball:

    52286
    missing magic number
    unable to read_digest
    couldn't verify signature
     -1
Output from attempt to extract a third-party tarball with the signature copied from a Dropbox tarball:

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

Re: How Dropbox Hacks Your Mac

#416
post #149

Earlier quoted context omitted.

At this point you need to follow up with convincing technical details of why Dropbox needs the circumvention to counter the accusation and rebuild the damaged trust. The reason for needing Accessibility API listed in your response is pretty vague, especially for those Mac users not having Microsoft products tainting their systems. I've deleted Dropbox from my Mac for now. I'm not installing it back till there's reaso…

I agree with you general sentiment, but would Word or Excel really "taint" your system?

I can't stand the `~/Documents/"Microsoft User Data"` folder, but that's what I get any time I open an Office app.

Re: How Dropbox Hacks Your Mac

#417

Earlier quoted context omitted.

Not from Dropbox but when you remove an app from accessibility permissions OS X will make you manually enable it again.

mikewhy: The article states that it re-adds itself to the list automatically the next time you log in, without asking for permission again. There's no option to keep it permanently disabled.

You could delete all of their suid helper binaries.

Re: How Dropbox Hacks Your Mac

#418
post #401

Earlier quoted context omitted.

I use it, but there's no iOS solution so I can't use it for a number of things.

BT-Sync is the original of syncthing with iOS-support but considered bad because its closed source and comercial I like it though

I don't use BT Sync because if I'm on my local university network they block BitTorrent. It's not a big deal since I've graduated, but I still go there and use the library and meet with people so it would be inconvenient.

Re: How Dropbox Hacks Your Mac

#419
post #26

Earlier quoted context omitted.

And if you're using Ubuntu, you're trusting package managers, and if you're using Gentoo, you're trusting original developers (how often do you audit source code?)

>And if you're using Ubuntu, you're trusting package managers, and if you're using Gentoo, you're trusting original developers This is correct. Consider, however, the motivations of the people involved. Apple's motivations are to make money from you. Debian's motiviations (intentionally avoiding Ubuntu here) are to make a good user-centric system. Packages are signed by named individuals that I can personally get to…

>> how often do you audit source code?

> You would be surprised!

How often do you audit OwnCloud's source code? (I'd describe it as "naive.")

Re: How Dropbox Hacks Your Mac

#420

Earlier quoted context omitted.

>And if you're using Ubuntu, you're trusting package managers, and if you're using Gentoo, you're trusting original developers This is correct. Consider, however, the motivations of the people involved. Apple's motivations are to make money from you. Debian's motiviations (intentionally avoiding Ubuntu here) are to make a good user-centric system. Packages are signed by named individuals that I can personally get to…

>> how often do you audit source code? > You would be surprised! How often do you audit OwnCloud's source code? (I'd describe it as "naive.")

I actually don't use OwnCloud, so never.
Post reply on HN