Live data from Hacker News

How Dropbox Hacks Your Mac

applehelpwriter.com

161–170 of 435 posts

Re: How Dropbox Hacks Your Mac

#161

I don't really understand the conclusion here. So the scenario is you trust dropbox with your files, and you trust them with a kernel blob implementing the filesystem, but you don't trust them to silently have accessibility rights?

>you trust dropbox with your files, and you trust them with a kernel blob implementing the filesystem, but you don't trust them to silently have accessibility rights? The problem here isn't that you don't trust them to have accessibility rights, it's that Dropbox has phished your root password, stored it, and will continue to modify your system to meet it's desired operating criteria.

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

Direct from the DB engineer at top of thread.

Re: How Dropbox Hacks Your Mac

#162
post #159
post #137

Earlier quoted context omitted.

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.

Re: How Dropbox Hacks Your Mac

#163

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! It doesn't really matter if you do. OpenSSL is one example showing there are critical mistakes of grand level everywhere, same as there might be cleverly hidden backdoor in that multi-100k source tree (or any of the myriad of dependencies) you "audited".

It's still a lot better than not having the source. There are tons of other benefits too. The one downside is CPU cost to compile everything yourself.

Re: How Dropbox Hacks Your Mac

#164

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…

It's very strange that after I remove Dropbox from the accessibility list you think it's ok to add it back in again. That's the reason I'll be closing my account.

Absolutely. I dropped Dropbox some time back, when it became obvious that they didn't respect the user's wishes at all.

This has been a long-standing thing with them - some years back there was some stink about the forced Dropbox branding in the Finder (which we now see is related to this). Many people (including me) found it rude that it insists on adding useless widgets, badging icons and inserting crap in the Finder sidebar. For whatever reason, Dropbox (the corporation) apparently believes that junk to be important enough to their business to disregard what the owner of the machine wants, and now we see the lengths they go through to force themselves on the user.

I used to simply consider Dropbox rude enough to make me not want to use it. Now that I see the company is actively going out of their way to break the intended function of security-related OS components, I now consider Dropbox malware and will begin warning others about the company.

Re: How Dropbox Hacks Your Mac

#165
I have given Dropbox access to my files, admins rights, and ability to run in the kernel. I'm not freaking out about the Accessibility API.

setuid binaries:

  $ tree -p /Library/DropboxHelperTools/
  /Library/DropboxHelperTools/
  ├── [-r-s--x--x]  DropboxHelperInstaller
  └── [drwxr-xr-x]  Dropbox_u501
      ├── [-r-s--x--x]  dbaccessperm
      ├── [-r-s--x--x]  dbfseventsd
      └── [-r-s--x--x]  dbkextd
kernel extension:

  $ kextstat -b com.getdropbox.dropbox.kext
  Index Refs Address            Size       Wired      Name (Version) UUID 
    163    0 0xffffff7f835b5000 0x6000     0x6000     com.getdropbox.dropbox.kext (1.7.5)

Re: How Dropbox Hacks Your Mac

#166
post #11

What the fuck Dropbox! How do I get rid of the backdoor in /Library/Application\ Support/com.apple.TCC/TCC.db even after uninstalling Dropbox.app and rm -rf'ing ~/.dropbox and /Library/DropboxHelperTools? Do I just sudo sqlite3 and delete the row? Or is there an official tool (tccutil)? Edit: Crap, there's a /Library/Extensions/Dropbox.kext too now. :(

> Crap, there's a /Library/Extensions/Dropbox.kext too

Now I'm getting paranoid. My /Library/Extensions/ directory contains the following kernel extensions. I purchased Little Snitch so I knew about theirs. Anyone have any comments on the rest of them?

  ACS6x.kext
  ATTOCelerityFC8.kext
  ATTOExpressSASHBA2.kext
  ATTOExpressSASRAID2.kext
  ArcMSR.kext
  BJUSBLoad.kext
  CIJUSBLoad.kext
  CalDigitHDProDrv.kext
  HighPointIOP.kext
  HighPointRR.kext
  LittleSnitch.kext
  PromiseSTEX.kext
  SoftRAID.kext

Re: How Dropbox Hacks Your Mac

#167

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…

Can you also tell us why Dropbox eats lots of CPU cycles anytime there is any filesystem activity? If I unzip a large archive in /tmp, Dropbox is eating 60% of my CPU. If I open the new Xcode for the first time (and the system verifies all the signatures) Dropbox is eating 100% of one CPU. It really seems like the Dropbox client is monitoring the entire filesystem (all FSEvents) instead of just the dropbox syncing fo…

Bingo.

It started with my laptop running incredibly slow. A bit of digging showed dropbox saturating an entire cpu core despite no recent changes being made to my dropbox folder. What was happening at the time is a lot of disk activity on a folder that Dropbox should know nothing about. I'm not 100% sure but it also seems to me that Dropbox is monitoring all FSEvents on my machine and doing something with them.

I've been a paying Dropbox user for several years, but this has tipped me over the edge. The only way to regain my trust at this point is providing an official explanation of what's going on, with technical details. I'm paying for a service to keep my files safe and sync them across devices, nothing more, nothing less. Now that I got the impression that Dropbox is doing something outside of that envelope, even if that impression is wrong, my money is going to go elsewhere, probably to a competitor.

Re: How Dropbox Hacks Your Mac

#168
post #11

What the fuck Dropbox! How do I get rid of the backdoor in /Library/Application\ Support/com.apple.TCC/TCC.db even after uninstalling Dropbox.app and rm -rf'ing ~/.dropbox and /Library/DropboxHelperTools? Do I just sudo sqlite3 and delete the row? Or is there an official tool (tccutil)? Edit: Crap, there's a /Library/Extensions/Dropbox.kext too now. :(

> Crap, there's a /Library/Extensions/Dropbox.kext too Now I'm getting paranoid. My /Library/Extensions/ directory contains the following kernel extensions. I purchased Little Snitch so I knew about theirs. Anyone have any comments on the rest of them? ACS6x.kext ATTOCelerityFC8.kext ATTOExpressSASHBA2.kext ATTOExpressSASRAID2.kext ArcMSR.kext BJUSBLoad.kext CIJUSBLoad.kext CalDigitHDProDrv.kext HighPointIOP.kext Hig…

I have all of those except "BJUSBLoad", "CIJUSBLoad" and "LittleSnitch".

Re: How Dropbox Hacks Your Mac

#169
post #125

Earlier quoted context omitted.

They do provide the OS, so they implicitly have access to all your files at a level that dropbox would have a hard time achieving.

> so they implicitly have access to all your files If you can demonstrate how Apple has access to my files on an OS X installation with no iCloud configured, I will round up a massive bounty.

Open your finder. Every file that you see has just been touched by apples code.

Your OS does have access to all files that you have on your computer. It manages all network connections. It exposes all information that tools such as little snitch display to you. Apple signs and provides all software updates to you. They control SPI and app sandboxing. I'm not saying that Apple does access your files. I do trust them not to since they've shown that they at least attempt to step up and defend themselves and their users. Still, they could if they wanted to.

Re: How Dropbox Hacks Your Mac

#170
post #159
post #137

Earlier quoted context omitted.

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

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.

Post reply on HN