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.
> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
To clarify for others: In /Library/DropboxHelperTools, you'll find a folder for each user full of setuid tools which run as root and do various privileged things. I assume that the client is presenting the normal OS X "ask for elevated access" UI and then using that elevated access to configure and install these. (I don't work for Dropbox or anything; I've just been poking around.)
> - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
@newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?
I understand the desire to make your features "just work", but circumventing the user's privacy controls to do that is never acceptable. Especially accessibility, which is basically a general warrant to snoop on everything the user does. You wouldn't be on my system anymore if my work didn't require Dropbox. You're going to lose a lot of trust over this, and it won't even be half of what you deserve.
And it's not even in your interest in the long term. This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement. Since Dropbox can't really do its job when it's locked in a sandbox, I really don't think that's what you guys want to happen.
Teams like yours are why we can't have nice things.
(P.S. plz respect NSFileCoordinator this isn't Tiger anymore kthxbai)
> @newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?
Yep, we’re going to fix this so that if you uncheck it, we leave it unchecked.
> This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
As alluded to elsewhere in this thread, this is already happening in macOS 10.12. We’ll be switching to the same approach that Steam (among others) do to request accessibility.
Wow, it's stunning that an app would install anything suid root.
Admittedly I'm not a Mac guy, but that can't be common practice.
And then the response isn't "we're going to stop endangering our users with this dangerous practice", it's "we're going to stop doing this one particular thing that happened to be called out this time".
> more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
Please feel free to duplicate my radar! Accessibility and Productivity/Utility app developers would love a Sandbox entitlement.
rdar://13570189 - Sandbox entitlement for Accessibility API to allow apps for the disabled
The Accessibility toolkit has always been off limits to Sandboxed apps, and no entitlement exists. This seems unlikely to change. It's unfortunate, as this keeps many good and useful apps out of the Mac App Store.
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 folders, and doing it relatively inefficiently at that.
At this point if I'm doing anything filesystem intensive I close Dropbox first.
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.
I feel bad for contributing to the hijacking of this thread, but I simply have to pitch in: please do something about the abysmal performance of Dropbox. We have what are practically supercomputers on our desks, and Dropbox has problems dealing with hundreds or low thousands of files. It is something you need to work on.
As to the original article, I think you have a lot of explaining to do and a lot to clean up. Too much has been swept under the rug.
Just checked this myself on a MacPro. You can see the DropBox process kick in with CPU usage while opening big apps like Photoshop or Xcode. Not a lot on this MacPro (~3%), but it's always in time with an app opening. Oddly there's no corresponding disk access associated with the Dropbox process when looking at it on the Disk tab of Activity Monitor.
Would definitely like an explanation of what's going on here.
Could this be a consequence of the built in FS APIs coming up short, as Ben put it, and forcing DropBox to do things in less efficient ways to work around the limitations?
Have you checked the version of the Dropbox client you're running? The auto-updater broke and silently failed many months ago (n=5 Macs) and I found a number of problems like that one had already been fixed but effectively never shipped.
(Support was prompt but basically “let us know if it happens again”)
I started to see this really happen when backing up. When Arq is doing some work, Dropbox is slamming the CPU. I checked with the Arq team and they said during the time I was monitoring it, there's no way they would be touching the Dropbox folder, so it really did seem like some kind of global intercept was going on and was killing the box. I guess this is as good a way as any to raise this -- Dropbox team, test with Arq!
Same problem. When working with or moving files in folders other than the dropbox folder, I still find the dropbox application taking up large amounts of CPU. Dropbox also, in the last few months, has been messing up my spotlight database and causing mdworker and fontd to use all available cpu.
Then I start getting console messages like this:
mds (Error) FMW: WE ARE DROPPING FMW EVENTS!
All disappears after disabling Dropbox (and rebuilding caches and the spotlight database)
I uninstalled the desktop client because of this exact issue. I just drag/drop via the web interface now. Might not work for some people, but it suits me fine.
I noticed a lot of disk activity once and fired up Process Monitor (on Windows). Dropbox.exe was going through literally all the files on my computer. That was when I uninstalled it forever.
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.
Most programs don't consider that you might try to explicitly revoke permissions. It's a very understandable bug/behavior. I think it's worth giving them a chance to amend that code.
Why would you even do that? What nefarious and yet undiscovered things did you think DropBox was likely to do specifically with the accessibility permission?
Permission systems in general seem like a solution without a problem to me. Nobody but a minority of people very concerned about theoretical security problems wanted them on platforms that didn't have them, almost nobody cares what permissions programs use on platforms that have them now, and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights today on Windows and Linux.
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 reasonable explanation and remedies.
I'm not affiliated with Dropbox, but compare the UX of Dropbox (type in your admin-password and that's it) with the one of Steam (opens the System preferences and forces you to make manual changes). Both need to be allowed accessibility access for one feature or another, but only one of them provides convincing UX.
For us power users, the "official" way is better, sure, but what's the percentage of power-users compared to normal users who actually enjoy the office intrgration and other things made possible by the accessibility API?
I would be happiest if it didn't do the dirty thing and also didn't offer office integration. Maybe that's the change they need to make. But if they insist on doing the things that need accessibility, then the current solution is so much more convenient than the steam dance.
Let's be honest about this. Dropbox has always been awful with security. They used to flat out lie about encryption (pretending they encrypted server side, when they weren't at all). They've had numerous other incidents, including ones where Arash treated affected customers horribly.
Dropbox has hired some good people, but the foundation consists of a great CEO, and a customer-hostile CTO who doesn't give a fuck about security. It will NEVER be a good product because of that.
Drew Houston would be WAY wealthier today if he'd fired that worthless piece of shit he calls a CTO years ago.
"We use elevated access for where the built-in FS APIs come up short."
One wonders what Dropbox would say if someone decided to obtain elevated access on their servers by surreptitious means because Dropbox's API "came up short".[1]
> The intent was never to frustrate people or override their choices
When you designed an agent that specifically overrides the user's choice to turn off Accessibility rights for Dropbox, frustrating that attempt, I suspect that was intentional.
Note: not excusing Dropbox, but understanding how they reached here.
Bob (who less technically savvy) installs Dropbox for use with Office. Chuck (someone more technical than Bob) removes Dropbox from the accessibility list. Chuck has now broken Bob’s Dropbox, and Bob (being less technically savvy) blames Dropbox resulting in another ongoing thread about broken Dropbox.
I completely understand how Dropbox reached this point, and purely from a technical support point of view, how it is justified. There are probably better ways for them to have done this (still have the “hack”, but only insert it if Office applications are detected to be installed; have an option that can turn it off even if Office is installed, but warn about it and make it “easy” to turn back on).
In the long run, the best way to demonstrate that your software is trustworthy is to release the source code for your client software under an open source license.
Regardless of the password issue, if you are legitimately working with Apple to get the granular access to implement the useful features you want, why would you in the meantime subvert Apple security mechanisms (by using a sql vulnerability - this already more than qualifies you as malware IMO) to sneak the features in rather than asking the user to grant the accessibility permission?? No, this is more than a "my bad," this is deceit and violating.
Uh, nope. You've just ensured Dropbox will never be installed again on any of my machines or devices. Ever. You fuck up like this, you never earn that trust back.
Office Integrations: Worthless for a huge swath of users who don't have Office. Also undesirable for a large group of users who have Office but have no use for the integration.
Other Integrations: Too vague to justify what is potentially a large security threat. You've really got to do better than that.
The dialog box you see is a native OS X API (i.e. made by Apple).
Which API are you using that allows you to circumvent the OS X Accessibility Permissions control dialog? Or do you mean you're simply asking for administrative permissions in order to write directly to TCC.db? And in that case, what mechanism are you using to circumvent the permissions structure to permit you to rewrite to TCC.db without re-requesting the user's permission?
If I understood correctly, using the root permission granted by the user when the prompt for the password comes up, they hack the database containing the accessibility settings, and add themselves to the list.
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.
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.
I removed the Dropbox app from my iPad when they started to require a active GPS to upload files. [about two years ago] If you disallow GPS for that app, it disallows you to upload files. Stupid decisions!?
Just wanted to give the author a shoutout for being awesome. This article is published with an AMP version[0] too, which is pretty unusual for smaller blogging sites.
AMP articles are so much easier on my eyes (and the author can't include their own javascript on an AMP page, so there is less bloat). I wish all bloggers started to publish AMP pages.
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.
This is what really confuses me about AMP. All it does, really, is force authors to strip their page down to core, performant components.
Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.
(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)
> Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place.
AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.
AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.
I can read all mentioned pages with NoScript enabled. But fully agreed that static pages such as blogs shouldn't require JS to show the primary content.
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.
I'd be a lot happier with AMP if they'd stop hijacking the scrolling behavior on iOS (speed and momentum is different than on a regular web page). It drives me absolutely crazy.
Oh no!! I never heard of AMP before but now I hate it with a passion. Anything that spreads the terrible gmail style scrolling behavior is all bad in my eyes.
> I wish all bloggers started to publish AMP pages.
I wish all bloggers with sites so bloated that AMP is a fundamental difference didn't feel they needed to include large image assets, custom fonts, and fancy JavaScript libraries (not suggesting this blogger does - just a general complaint).
In case there are any Wordpress bloggers and authors out there who would like to add AMP functionality to their websites Automattic put together a nice plugin tool to do just that.[0] I wonder when this will become part of the wp-core?
I work Syncplicity, a Dropbox competitor and investigated building a feature that is similar to the Dropbox badge. (We call it the App Tab. Basically, it's UI that tacks onto Office that tells you that someone else is editing the same document.)
We've had requests for this feature for years. I can't stress how much customers request this feature; it's put a lot of egg on our face that Dropbox beat us to it.
In order to do this on Mac, we'd need to register ourselves as an accessibility client. I don't remember the details about registering ourselves, but from what I remember, it doesn't require hacking into OSX.
We've had to hack into OSX in the past: Adding menu items and icons to Windows Explorer is supported via well-documented Microsoft APIs. It wasn't until about 2014 that Apple supported this, prior to that, we had to reverse-engineer Finder. We didn't get OSX APIs to do this until we hired a contractor with "connections" to Apple he petitioned his connections to provide an API. I know that Dropbox, Google Drive, Box, and an open-source project called Liferay-Nativity all performed the same hack.
Based on my Syncplicity experience is that, what happens in these cases, is that a product manager gets so focused on the pixels that he/she is completely blind to the practical implementations. There's probably a bit of "I told you so" coming from some of Dropbox's engineers now.
Or maybe, just maybe, the PM doesn't care about having to "hack" into Mac, because most Dropbox customers just don't care and would rather the service they are paying for is functional. Just a thought.
It looks like in 10.12 Apple has added TCC.db to SIP, so this will no longer work — Dropbox will, hopefully, actually be forced to request accessibility access like they're supposed to. I'm sure they'll still demand your admin password via a dialog that tries super hard to look like a system one to use for whatever other more or less nefarious purposes. Would be nice if there was an alternative that actually syncs as reliably and performantly, but in my testing that's very much not the case.
I appreciate the trend of Apple forcing Dropbox to stop doing dumb shit, though. (Previously, of course, the SIMBL-style Finder hacking)
That last comment is ironic, given that Dropbox would literally not exist today without the runtime patching of the Finder.
There was no other way to do what they did. The only reason Apple added API was because Dropbox came up with an idea that demonstrated the need for such an API to exist.
Yes, last time I tried it, had a variety of conflict issues plus the client had some problems, performance and otherwise. If you're just using it as a backup solution (does it even keep file history?) from a single machine + mobile/web access, it may well work acceptably.
When I last tried it the performance was abysmal, almost as bad as Google Drive. Also, no Linux client. I didn't use it enough to know if it has the same conflict issues as many of the other ones I tried — Microsoft may well have managed to get that right.
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".
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.
> 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.
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."
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".
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.
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.
Great article, but poor conclusion. He finds that Dropbox is untrustworthy, a finding that likely surprises no one, and reaches for iCloud as the solution. Why move into another walled garden driven by corporate interests? OwnCloud or a similar self hosted solution would be better. I just use NFS and a dead simple storage server to make ~/shared available on all of my machines.
Because Apple doesn't have a mechanism to access files on your Mac, while they do have a mechanism to access files on iCloud. This means someone guessing your security questions, or somebody with a warrant, or somebody abusing their access rights can get to your files.
In many cases self hosted is better. One needs to consider that this also needs some time to maintain, though. Personally I also like ownCloud but still mostly use Dropbox.
agreed. The cost of hard disk/ssd storage is constantly falling, I hate having my crap locked up in the "cloud" knowing that if I miss a couple payments it's toast.
Dropbox circumventing security restrictions (albeit for legit reasons) is particularly worrying because they have board members who support warrentless surveillance.
In my mind Dropbox became a company not worth supporting when Rice joined Dropbox's board (http://www.drop-dropbox.com/). Personally, with a board member who advocates warrentless surveillance it seems unlikely that we share similar views on the security of my data, and I wont be using their service.
The combo of Rice and now this revelation that Dropbox gains user-level access to your files (and network resources) really makes me wonder if Dropbox isn't really a NSA plant.
What better way to gain access to users' files than through a startup's free app that demands your password?
Honestly they're pretty much the most expensive out of all of the storage solutions. Other than versioning they have less features than their competition as well. If they were born today I can't imagine they would have gone much of anywhere. Not sure how they're doing financially today but it seems each product they create flops.
So even outside of this surveillance stuff I don't get the point in using them.
Their client just works better at syncing quickly and reliably. A huge criteria for me is how much CPU it uses in the background compared to competing solutions from Google or MS and it was often an order of magnitude less (other clients may have improved in the last year or two, I haven't checked).
Another significant advantage is that they support a stable command line client for Linux.
As far as I know, DropBox is the only service that does delta block uploads correctly and switches to LAN transfer when two synced computers are in the same network.
I know it's CS 101, but neither Google Drive, iCloud, or OneDrive do this.
Not to mention the other services have bizarre naming limits (e.g., dotfiles are forbidden on OneDrive).
I've used Dropbox for quite some years because they were (one of) the first and rock-solid. Especially the latter is very important for a service like this.
Oh, and they always supported the big three OSes.
These last two features makes them stand out against the myriad of alternatives. (Especially the offerings from Apple, Google and Microsoft are laughably bad.)
Dropbox is more expensive but not that more expensive given that it just works.
That said, I switched a couple of months ago to Seafile (the German branch) and it has worked almost as good as Dropbox.
The reasons for switching were: not based in the US, supports more OSes, Rice, cheaper.
Some features like selective syncing do not work as well but others like multiple libraries are a solid addition.
I have run into a Git repo issue on Seafile that I never had on Dropbox and the client on Windows could not sync some files due to the filenames (luckily those could be renamed).
Totally distributed, works like magic. Being distributed means you do have to blindly trust a third party, but also that don't have to worry about $ per megabite. For example, one of the machines I have in my Syncthing network is a Raspberry Pi with a 3TB drive getting a backup of my laptop $HOME and important stuff from other machines all the time.
Dropbox trying to find ways to push the platform is a good thing not a bad thing.
If anything Apple have put so many restrictions on OSX and isn't pushing for much innovation on their side to allow people to build ever more powerful apps.
I understand general security concerns but I don't understand the critique of a company like Dropbox. They are doing the user er service not a disservice by finding a balance between pushing the platform forward while still taking your security concerns into account.
I would personally be more concerned with the fact that Apple haven't done anything fundamental for the osx platform in quite a while which is the exact opposite of what they have done for iOS.
Dropbox is using cached root privs that it now claims it doesn't even need to force itself into full control of your machine, on the back of an accessibility exploit, actively disregards explicit user actions taken to remove it, does this all via SQL injection, and if all of the above doesn't meet the definition of malware, I don't know what does.
All this from a company who recently had one of the largest credential breaches in the history of the Internet
and you think it's okay to "push the platform"?!???!
It's pretty popular these days to say "Delete your account" online. If this wasn't an accidental knee jerk response, please go one step farther and delete any professional involvement you have with software or technology implementation. You don't understand security concerns, nor does your poorly rehashed half-argument about OS X explain why this would be okay on any platform.
A bit emphatic, but if those goes to the greys, so be it. HN is clearly frequented by people with meaningful input in business, product, and engineering decisions. This kind of scapegoat deflection needs to be highlighted as an unacceptable security practice not justified by anything that seems to qualify as entrepreneurial disruption.
Of course you can claim it's malware, but sometimes malware works FOR the user not against them this is an example of that.
If anything you should put your anger towards Apple who haven't done anything to osx platform for ages.
With regards to security I both understand it and take it very seriously but I have no interest in theoretical debates. In this specific case I have no issue with what Dropbox is doing. I have an issue that Apple haven't found a way to make these things possible without the exploit.
If you feel strongly about it, be my guest delete all your accounts. I see no reason not to trust Dropbox, but hey each to their own.
The fact that any application can spoof the os password prompt makes me wonder why they don't have a prominent feature to show the prompt is from the OS. On windows there is the secure desktop with the dimming effect.
Note that that is not what that "effect" is for. It's not, strictly speaking, even an actual "effect". Windows is creating and attaching another "desktop" to your screen, and putting the dialog there. The alternate "desktop", the "Secure Desktop", is inaccessible from any other software on the computer, so a piece of malware can't say "Ask for permission to do blah, then find the 'Allow' button and click it" The "dimming" is to make it clear that this dialog is completely modal, and you can't get to anything else while it's around. It's in no way meant as a "Look, this is an OS prompt", and it's quite easy to match the effect from another program, just grab a screenshot, dim it, throw it up full screen, then throw your dialog in front of it.
This is true, but in terms of how the user interacts with the dialog, they can more or less associate the dimmed background and Secure Desktop dialog box with a "from the OS" behaviour. This happens because as you said, the secure desktop is "inaccessible from any other software on [your] computer."
I don't actually know if I fully believe that. I haven't seen the internals of how it's implemented, but at the very least most users can assume that only the OS can bring up the prompt, and only the user can make it go away.
That reminds of how Windows asks you to press "ctrl+alt+del" before typing your account password in some situations, because other software cannot intercept ctrl+ald+del so you know the login prompt is legit.
That was actually designed to avoid typing credentials into "faked" password dialogs. The above mentioned "Secure Desktop" with dimming is not designed for that, but for the, rather hilarious, fact that it is trivial for a Windows program to hit any button on the screen it wants to. Having the permission requests pop up on a "Secure Desktop" prevents a malicious program from hitting the "Allow" button for it's own permission request. The funny part is that this is the exact kind of functionality dropbox is "hacking" itself access to.
It probably is, but it would be near-impossible for a respectable company to claim that they weren't specifically trying to spoof it.
With the current OS X password prompt being a benign looking window, Dropbox (or others) can easily say they're just "following standard UI patterns" or something like that.
Trivially, in fact, KeePass does a fairly good job of it, mimicing everything down to the actual creation of a second, "secure" desktop. It's arguably more secure, though it's a little bit of a "false security", as KeePass's "Secure Desktop" is not as "secure" as the UAC and similar one, as the UAC one runs as SYSTEM, where as KeePass's runs as the current user.
Not really. Sure you can make a replica of it but it won't behave the same because you'll be able to minimize or close it but the secure desktop you can't do jack to until you either accept to decline whatever it's asking.
It's not spoofing the prompt. The prompt is OS X native, DB is basically telling the OS "Hey I need root", the OS displays the prompt, and grants root access to DB. So it is a system prompt
Well, in theory they might, in practice they don't.
Almost all of the viruses reported for Macs were in fact Trojans.
And even if there were a few legitimate viruses over the years, none went very far as to cause much trouble to any sizeable number of people. Contrast with the barrage of Windows viruses and widespread mayhem they cause, on a platform were almost everybody uses an antivirus too.
It's not "just" due to the Mac being less popular either. Mac OS up to 9 got lots of viruses back in the day, and Macs had just 1 to 2% market share in the US. Nowadays they have several times that.
So yeah, on my Mac and Linux boxes, I'll care about viruses to the point of running an antivirus or such when people actually start getting some...
One thing to note: For non-sandboxed apps like Dropbox, the Accessibility API permissions don't really decrease security by a lot (in my opinion).
Most bad things can be done without the Accessibility API, e.g. apps can act as key loggers, take screenshots, encrypt all files your user can access, upload arbitrary things (unless you have a firewall enabled), synthesize mouse & keyboard events etc.
The Accessibility API makes some of those things easier, but if someone really wanted to attack you, he wouldn't need the Accessibility API.
For sandboxed apps the situation is quite different, because the Accessibility API would allow those apps to break out of the sandbox.
But of course Dropbox should have asked the user...
no, only if you use the cocoa/carbon apis. Using IOKit it doesn't need access to the Accessibility API. However IOKit is blocked for sandboxed applications.
I'm using the same techniques for my apps to enable accessibility access (which is needed for window management), although I'm asking users for confirmation before doing so.
It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users.
Why not displaying a simple yes/no popup similar to the "allow access to contacts / calendar items" dialog?
Because granting accessibility access is far more dangerous than granting access to contacts / calendar. The latter just exposes some of your user data. The former gives the app a huge amount of control over your computer.
What exactly is so dangerous? Any app can take screenshots , listen to keyboard entries, send keys, move the mouse pointer and upload stuff to a server without any AXApi permission.
Forbidding window movement doesn't add any security at all.
Anyways, all I want a simple prompt explaining what the Accessibility API does and yes/no buttons.
I've recently started using Syncthing to synchronize files between different machines. I'm super impressed at the quality of the application, its stability, and the documentation. Syncthing is written in go and open source. https://syncthing.net/
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?
If we're worried about theoretical abuse, the client could access all of your files because it runs as you.
You can opt out of the kernel extension? Still, you give it root to install, and it has a long history of hacking the file browser to get icon overlays... it seems weird to me that this would be a deciding factor.
>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.
I wonder what will happen when Apple plugs those security holes. Will Dropbox cease to run as it does now, and suddenly for instance lose important features?
This appears to be impossible in Sierra, as the relevant db has been added to SIP. I have un-granted access, and the dropbox app has not been able to re-enable it, nor has it complained (and yes, I restarted).
I didn't see it linked, so here's the Stack Overflow thread that documents some of these sqlite3 hacks for enabling access for assistive devices programmatically.
> No, there is no way to circumvent the need for visiting this screen. It is one of the operating system's base protections. Any way that is found to circumvent this will almost certainly be patched out. – Jul 17 '13
My Dropbox story: after I upgraded from Mountain Lion to El Capitan, the sidebar in the Finder went buggy (no way to remove a folder from the sidebar without restarting the Finder). After I started arranging for this next command line to run at the start of every OSX session, the bug went away: `killall -9 garcon`. This garcon identifies itself in Activity Monitor as "Dropbox Finder Integration".
Needless to say, I never asked or gave consent for Dropbox to integrate with the Finder (and sync still seems to continue to work after I disabled it).
I noticed about 6 months ago that Dropbox was on this list and disabled it the normal way. It stayed disabled and also didn't cause any problems using the software.
Anybody know a good OS X app to scan the file system for suid binaries? I guess I could do this with find from the shell, but a little utility app with a nice ui (and possibily some integration with a database to hide or categorize by threat level) seems like a smart thing to have on my system and run every so often.
Yeah, I guess that's probably good enough. I knew I could do this but was sort of thinking it would be nice to have a little dedicated tool that filters out or separates all the "known should be suid" -- and maybe tracks changes over time ... An interface to check periodically to quickly keep abreast of what's changing ...
I wonder if Apple will thwart this hack with an update. Seems like anyone reading this will start using this hack. In the meantime a watchdog app on this hack would be nice to have and share with the world.
I don't use OSX or apple software anymore - but I remember that using dropbox on osx always felt like it went against apple's UX flow. I ended up getting really frustrated with it.
If anything is overpriced, tarsnap is -- or was, last time I compared prices. Also picodollars are a bit opaque.
I really wanted to use it and hoped it'd come out reasonably compared to alternatives, but I actually found none except buying a hard disk + raspberry pi myself and hosting it at a friend's place. That was cheaper by about a factor 2, which (at 3TB data) was too much to ignore for my student budget. This was about two years ago though.
Indeed. Resilio Sync is a peer to peer synchronization tool, so data is not stored in the cloud. If you want a permanent cloud peer, Resilio Sync has the option of creating encrypted read-only secrets that you can use on a cloud peer. Such a peer will participate in the swarm, but will only see ciphertext data.
The application does not ask or require root access. And they support Linux and FreeBSD as well.
SyncThing should also be mentioned. However, if you want to share folders to other people as well, Resilio Sync seems to be the best option.
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?
If you need real-time file syncing, you could run a lightweight Linux install in VirtualBox and install Dropbox there. Dropbox on Linux runs in userspace (not as root) and so it's much more secure. Share the file between VirtualBox/Linux and your Mac, and you're done.
I knew something was odd with DropBox because I never saw any other application provide the level of integration they did. After the DropBox hacks, I reevaluated my security needs and the value I got from DropBox and decided to switch to OneDrive.
OneDrive's shell integration on the Mac isn't as good as DropBox's. Microsoft is aware of this and says they're trying to address it.
Now I know why it's so hard to do! If you want to play by the rules, you can't get the seamless integration you need.
Even with the restrictions though, OneDrive works pretty well on the Mac.
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.
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.
> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
To clarify for others: In /Library/DropboxHelperTools, you'll find a folder for each user full of setuid tools which run as root and do various privileged things. I assume that the client is presenting the normal OS X "ask for elevated access" UI and then using that elevated access to configure and install these. (I don't work for Dropbox or anything; I've just been poking around.)
> - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
@newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?
I understand the desire to make your features "just work", but circumventing the user's privacy controls to do that is never acceptable. Especially accessibility, which is basically a general warrant to snoop on everything the user does. You wouldn't be on my system anymore if my work didn't require Dropbox. You're going to lose a lot of trust over this, and it won't even be half of what you deserve.
And it's not even in your interest in the long term. This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement. Since Dropbox can't really do its job when it's locked in a sandbox, I really don't think that's what you guys want to happen.
Teams like yours are why we can't have nice things.
(P.S. plz respect NSFileCoordinator this isn't Tiger anymore kthxbai)
> @newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?
Yep, we’re going to fix this so that if you uncheck it, we leave it unchecked.
> This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
As alluded to elsewhere in this thread, this is already happening in macOS 10.12. We’ll be switching to the same approach that Steam (among others) do to request accessibility.
20 replies →
Wow, it's stunning that an app would install anything suid root.
Admittedly I'm not a Mac guy, but that can't be common practice.
And then the response isn't "we're going to stop endangering our users with this dangerous practice", it's "we're going to stop doing this one particular thing that happened to be called out this time".
1 reply →
> more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
Please feel free to duplicate my radar! Accessibility and Productivity/Utility app developers would love a Sandbox entitlement.
rdar://13570189 - Sandbox entitlement for Accessibility API to allow apps for the disabled
The Accessibility toolkit has always been off limits to Sandboxed apps, and no entitlement exists. This seems unlikely to change. It's unfortunate, as this keeps many good and useful apps out of the Mac App Store.
5 replies →
Not from Dropbox but when you remove an app from accessibility permissions OS X will make you manually enable it again.
2 replies →
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 folders, and doing it relatively inefficiently at that.
At this point if I'm doing anything filesystem intensive I close Dropbox first.
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.
I feel bad for contributing to the hijacking of this thread, but I simply have to pitch in: please do something about the abysmal performance of Dropbox. We have what are practically supercomputers on our desks, and Dropbox has problems dealing with hundreds or low thousands of files. It is something you need to work on.
As to the original article, I think you have a lot of explaining to do and a lot to clean up. Too much has been swept under the rug.
Just checked this myself on a MacPro. You can see the DropBox process kick in with CPU usage while opening big apps like Photoshop or Xcode. Not a lot on this MacPro (~3%), but it's always in time with an app opening. Oddly there's no corresponding disk access associated with the Dropbox process when looking at it on the Disk tab of Activity Monitor.
Would definitely like an explanation of what's going on here.
Could this be a consequence of the built in FS APIs coming up short, as Ben put it, and forcing DropBox to do things in less efficient ways to work around the limitations?
9 replies →
Have you checked the version of the Dropbox client you're running? The auto-updater broke and silently failed many months ago (n=5 Macs) and I found a number of problems like that one had already been fixed but effectively never shipped.
(Support was prompt but basically “let us know if it happens again”)
I started to see this really happen when backing up. When Arq is doing some work, Dropbox is slamming the CPU. I checked with the Arq team and they said during the time I was monitoring it, there's no way they would be touching the Dropbox folder, so it really did seem like some kind of global intercept was going on and was killing the box. I guess this is as good a way as any to raise this -- Dropbox team, test with Arq!
Same problem. When working with or moving files in folders other than the dropbox folder, I still find the dropbox application taking up large amounts of CPU. Dropbox also, in the last few months, has been messing up my spotlight database and causing mdworker and fontd to use all available cpu.
Then I start getting console messages like this: mds (Error) FMW: WE ARE DROPPING FMW EVENTS!
All disappears after disabling Dropbox (and rebuilding caches and the spotlight database)
Behaviour seen on multiple macs I own.
I uninstalled the desktop client because of this exact issue. I just drag/drop via the web interface now. Might not work for some people, but it suits me fine.
4 replies →
As important as this question is for usability, it seems off the original post's topic of Dropbox circumventing accessibility prompts.
Same problem here. My 3 year-old i5 Retina MacBook Pro is often slow because Dropbox uses 100 % of one CPU. And it gets hot too …
I noticed a lot of disk activity once and fired up Process Monitor (on Windows). Dropbox.exe was going through literally all the files on my computer. That was when I uninstalled it forever.
Yeah, I'm more curious as to why Dropbox corrupted a few of my PDFs. Has been happening for years for a variety of people.
2 replies →
Same problem here. My 3 year-old i5 Retina MacBook Pro is often slow because Dropbox uses 100 % of one CPU. And it gets hot too …
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.
3 replies →
Most programs don't consider that you might try to explicitly revoke permissions. It's a very understandable bug/behavior. I think it's worth giving them a chance to amend that code.
1 reply →
I closed my account when they put a former Secretary of State and National Security Advisor on the Board of Directors for no apparent reason.
Why would you even do that? What nefarious and yet undiscovered things did you think DropBox was likely to do specifically with the accessibility permission?
Permission systems in general seem like a solution without a problem to me. Nobody but a minority of people very concerned about theoretical security problems wanted them on platforms that didn't have them, almost nobody cares what permissions programs use on platforms that have them now, and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights today on Windows and Linux.
12 replies →
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 reasonable explanation and remedies.
> why Dropbox needs the circumvention
I'm not affiliated with Dropbox, but compare the UX of Dropbox (type in your admin-password and that's it) with the one of Steam (opens the System preferences and forces you to make manual changes). Both need to be allowed accessibility access for one feature or another, but only one of them provides convincing UX.
For us power users, the "official" way is better, sure, but what's the percentage of power-users compared to normal users who actually enjoy the office intrgration and other things made possible by the accessibility API?
I would be happiest if it didn't do the dirty thing and also didn't offer office integration. Maybe that's the change they need to make. But if they insist on doing the things that need accessibility, then the current solution is so much more convenient than the steam dance.
1 reply →
I agree with you general sentiment, but would Word or Excel really "taint" your system?
5 replies →
Let's be honest about this. Dropbox has always been awful with security. They used to flat out lie about encryption (pretending they encrypted server side, when they weren't at all). They've had numerous other incidents, including ones where Arash treated affected customers horribly.
Dropbox has hired some good people, but the foundation consists of a great CEO, and a customer-hostile CTO who doesn't give a fuck about security. It will NEVER be a good product because of that.
Drew Houston would be WAY wealthier today if he'd fired that worthless piece of shit he calls a CTO years ago.
"We use elevated access for where the built-in FS APIs come up short."
One wonders what Dropbox would say if someone decided to obtain elevated access on their servers by surreptitious means because Dropbox's API "came up short".[1]
[1] https://www.dropboxforum.com/hc/en-us/community/posts/204550...
I really wish there was some type of option to go "I really don't want all that fancy crap; give me the version that works via standard APIs"
That is the web UI.
> We use elevated access for where the built-in FS APIs come up short.
Can you please provide an example of such shortcomings and accessibility APIs that are better?
Setting the icon of a folder. Seriously. That's what they are using it for.
> The intent was never to frustrate people or override their choices
When you designed an agent that specifically overrides the user's choice to turn off Accessibility rights for Dropbox, frustrating that attempt, I suspect that was intentional.
Note: not excusing Dropbox, but understanding how they reached here.
Bob (who less technically savvy) installs Dropbox for use with Office. Chuck (someone more technical than Bob) removes Dropbox from the accessibility list. Chuck has now broken Bob’s Dropbox, and Bob (being less technically savvy) blames Dropbox resulting in another ongoing thread about broken Dropbox.
I completely understand how Dropbox reached this point, and purely from a technical support point of view, how it is justified. There are probably better ways for them to have done this (still have the “hack”, but only insert it if Office applications are detected to be installed; have an option that can turn it off even if Office is installed, but warn about it and make it “easy” to turn back on).
In the long run, the best way to demonstrate that your software is trustworthy is to release the source code for your client software under an open source license.
Regardless of the password issue, if you are legitimately working with Apple to get the granular access to implement the useful features you want, why would you in the meantime subvert Apple security mechanisms (by using a sql vulnerability - this already more than qualifies you as malware IMO) to sneak the features in rather than asking the user to grant the accessibility permission?? No, this is more than a "my bad," this is deceit and violating.
Uh, nope. You've just ensured Dropbox will never be installed again on any of my machines or devices. Ever. You fuck up like this, you never earn that trust back.
>We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
If that's the case, How is it that the accessibility preferences are changed without root authorization?
Once you type your password into the Apple dialog, you grant Dropbox root access. That's the purpose of this dialog in all cases.
3 replies →
Office Integrations: Worthless for a huge swath of users who don't have Office. Also undesirable for a large group of users who have Office but have no use for the integration.
Other Integrations: Too vague to justify what is potentially a large security threat. You've really got to do better than that.
The dialog box you see is a native OS X API (i.e. made by Apple).
Which API are you using that allows you to circumvent the OS X Accessibility Permissions control dialog? Or do you mean you're simply asking for administrative permissions in order to write directly to TCC.db? And in that case, what mechanism are you using to circumvent the permissions structure to permit you to rewrite to TCC.db without re-requesting the user's permission?
The Accessibility Permissions dialogue doesn't just show up. You as a developer can control when it is shown (using AXIsProcessTrustedWithOptions).
It would be awesome to have it not use accessibility APIs. I'm going to be following the instructions to revoke those rights.
I still don't understand how this allows for accessibility circumvention dialog.
If I understood correctly, using the root permission granted by the user when the prompt for the password comes up, they hack the database containing the accessibility settings, and add themselves to the list.
>but unfortunately some of the permissions aren’t as granular as we would like.
Nice euphemism for "catch all" permissions...
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.
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):
Output from attempt to extract a third-party tarball:
Output from attempt to extract a third-party tarball with the signature copied from a Dropbox tarball:
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.
That office integration is a PITA, is there anyway to disable it?
On a Mac: Click Dropbox Icon in the menubar -> Options (gear in bottom right) -> General -> set Dropbox badge to "Never Show"
Now a malware can target your scripts and get a free ride to all your system yay.
@newhouseb
Off topic: can you help me understand why when a file is locked (e.g. Outlook accessing .PST file) this causes Dropbox to peg the CPU to 100%.
I've opened multiple bug reports over the years and support dismisses my finding.
This makes Dropbox un-usable for me. I literally have to run Dropbox as "paused" 90% of the time and only "unpause" Dropbox when I close Outlook.
>We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
Is it a native OS X dialog API, or native OS X authentication API? I could make a password prompt myself, and call that "being official Win32 API".
Can you show me the class where you invoke it, so I can judge for myself?
It's a standard OS X authentication API. The overview of the authorization stuff is discussed in:
https://developer.apple.com/library/mac/documentation/Securi...
If you look under "Authorization Services Tasks" you'll see there's details about calling a privileged installer.
You are really just digging the hole deeper at this point. This needs a mea maxima culpa.
Apple really should kick you from the App Store and blacklist dropbox as malware.
I don't think Dropbox is listed on the App Store (I doubt it meets the sandboxing restrictions)
2 replies →
> We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.
And as for the rest of the privileges, we just take them without asking. Who knows, someone might refuse!
I removed the Dropbox app from my iPad when they started to require a active GPS to upload files. [about two years ago] If you disallow GPS for that app, it disallows you to upload files. Stupid decisions!?
wat. I just checked, I have Location Services set to 'Never' on Dropbox and it uploads files fine.
1 reply →
No problem. I've deleted dropbox and looking at alternatives. So far, they're cheaper for more space and don't pull this bullshit.
Just wanted to give the author a shoutout for being awesome. This article is published with an AMP version[0] too, which is pretty unusual for smaller blogging sites.
AMP articles are so much easier on my eyes (and the author can't include their own javascript on an AMP page, so there is less bloat). I wish all bloggers started to publish AMP pages.
[0] - http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
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...
AMP is bastardized HTML used as an excuse to making a website fast in the first place. I totally agree.
Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." [1]
Who gave them the authority?
AMP worries me greatly.
[1] https://github.com/ampproject/amphtml/blob/master/builtins/a...
5 replies →
This is what really confuses me about AMP. All it does, really, is force authors to strip their page down to core, performant components.
Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.
(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)
> Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place.
AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.
AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.
1 reply →
I can read all mentioned pages with NoScript enabled. But fully agreed that static pages such as blogs shouldn't require JS to show the primary content.
8 replies →
> 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.
1 reply →
The site is running on WordPress.com where every site has AMP enabled: https://en.blog.wordpress.com/2016/02/24/amp-for-wordpress-d...
AMP integration still a work in progress, but getting better: https://github.com/Automattic/amp-wp
I'd be a lot happier with AMP if they'd stop hijacking the scrolling behavior on iOS (speed and momentum is different than on a regular web page). It drives me absolutely crazy.
Oh no!! I never heard of AMP before but now I hate it with a passion. Anything that spreads the terrible gmail style scrolling behavior is all bad in my eyes.
Why not an "HTML with minimal styles and no JavaScript" version? Oh wait, that's not reactive.
It can be:
http://motherfuckingwebsite.com/
6 replies →
> I wish all bloggers started to publish AMP pages.
I wish all bloggers with sites so bloated that AMP is a fundamental difference didn't feel they needed to include large image assets, custom fonts, and fancy JavaScript libraries (not suggesting this blogger does - just a general complaint).
Hey, I remember WAP!
AMP is terrible for publishers though. It would be better if the site would publish simpler HTML/JS than use AMP.
Kudos to the OP for doing it, and for anyone using WordPress, it's pretty easy for you to do it too:
https://wordpress.org/plugins/amp/
In case there are any Wordpress bloggers and authors out there who would like to add AMP functionality to their websites Automattic put together a nice plugin tool to do just that.[0] I wonder when this will become part of the wp-core?
[0] https://github.com/Automattic/amp-wp
I hope never. This is clearly the sort of thing that should be optional--which is exactly why Wordpress has a plugin system.
This is how the entire web should be, honestly.
I agree, it was a great read!
I work Syncplicity, a Dropbox competitor and investigated building a feature that is similar to the Dropbox badge. (We call it the App Tab. Basically, it's UI that tacks onto Office that tells you that someone else is editing the same document.)
We've had requests for this feature for years. I can't stress how much customers request this feature; it's put a lot of egg on our face that Dropbox beat us to it.
In order to do this on Mac, we'd need to register ourselves as an accessibility client. I don't remember the details about registering ourselves, but from what I remember, it doesn't require hacking into OSX.
We've had to hack into OSX in the past: Adding menu items and icons to Windows Explorer is supported via well-documented Microsoft APIs. It wasn't until about 2014 that Apple supported this, prior to that, we had to reverse-engineer Finder. We didn't get OSX APIs to do this until we hired a contractor with "connections" to Apple he petitioned his connections to provide an API. I know that Dropbox, Google Drive, Box, and an open-source project called Liferay-Nativity all performed the same hack.
Based on my Syncplicity experience is that, what happens in these cases, is that a product manager gets so focused on the pixels that he/she is completely blind to the practical implementations. There's probably a bit of "I told you so" coming from some of Dropbox's engineers now.
Or maybe, just maybe, the PM doesn't care about having to "hack" into Mac, because most Dropbox customers just don't care and would rather the service they are paying for is functional. Just a thought.
Nobody cares about security, until they have a security problem.
It looks like in 10.12 Apple has added TCC.db to SIP, so this will no longer work — Dropbox will, hopefully, actually be forced to request accessibility access like they're supposed to. I'm sure they'll still demand your admin password via a dialog that tries super hard to look like a system one to use for whatever other more or less nefarious purposes. Would be nice if there was an alternative that actually syncs as reliably and performantly, but in my testing that's very much not the case.
I appreciate the trend of Apple forcing Dropbox to stop doing dumb shit, though. (Previously, of course, the SIMBL-style Finder hacking)
That last comment is ironic, given that Dropbox would literally not exist today without the runtime patching of the Finder.
There was no other way to do what they did. The only reason Apple added API was because Dropbox came up with an idea that demonstrated the need for such an API to exist.
Their only feature which necessitated that, as far as I know, was the sync status badge display which is hardly necessary to the product.
3 replies →
I use owncloud (and then dropbox inside it so some files are double backed up). I find it to be just fine. Have you had any problems with it?
Yes, last time I tried it, had a variety of conflict issues plus the client had some problems, performance and otherwise. If you're just using it as a backup solution (does it even keep file history?) from a single machine + mobile/web access, it may well work acceptably.
3 replies →
We use OneDrive at work and it works pretty much exactly as well as I recall Dropbox working back when I used it.
When I last tried it the performance was abysmal, almost as bad as Google Drive. Also, no Linux client. I didn't use it enough to know if it has the same conflict issues as many of the other ones I tried — Microsoft may well have managed to get that right.
1 reply →
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.
> 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.
3 replies →
How's that any different compared to Linux? AFAIK apt packages can run arbitrary scripts as root.
10 replies →
"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."
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.
4 replies →
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".
That skips the important point that it's not supposed to be possible for even root to do this without a prompt.
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.
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.
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:
kernel extension:
Dropbox on Linux needs none of that. Sure it doesn't have the fancy icons in file managers, but it also runs in user-space without a kernel module.
There are plugins that give you the fancy icons for some file managers, and they still run in user-space (and as non-root).
2 replies →
Since the arrival of FSEvents I don't understand why DB needs a kernel mod at all
Dropbox Infinite:
https://news.ycombinator.com/item?id=11570888
Great article, but poor conclusion. He finds that Dropbox is untrustworthy, a finding that likely surprises no one, and reaches for iCloud as the solution. Why move into another walled garden driven by corporate interests? OwnCloud or a similar self hosted solution would be better. I just use NFS and a dead simple storage server to make ~/shared available on all of my machines.
If you're going to use a Mac, you're trusting Apple already. How does using iCloud make you trust them more?
Because Apple doesn't have a mechanism to access files on your Mac, while they do have a mechanism to access files on iCloud. This means someone guessing your security questions, or somebody with a warrant, or somebody abusing their access rights can get to your files.
8 replies →
I wouldn't use a Mac, either :)
13 replies →
"OwnCloud or a similar self hosted solution would be better."
Perhaps better for limited use cases that don't really apply to the vast majority of Dropbox's user base.
You start off comparing apples to oranges, and with your latter solution, you aren't even comparing to fruit anymore.
What happens when you take a laptop to another network?
Everything freaks out, unfortunately. I would work on a better solution, but I'm not particularly inconvenienced by this issue.
3 replies →
In many cases self hosted is better. One needs to consider that this also needs some time to maintain, though. Personally I also like ownCloud but still mostly use Dropbox.
agreed. The cost of hard disk/ssd storage is constantly falling, I hate having my crap locked up in the "cloud" knowing that if I miss a couple payments it's toast.
Dropbox circumventing security restrictions (albeit for legit reasons) is particularly worrying because they have board members who support warrentless surveillance.
In my mind Dropbox became a company not worth supporting when Rice joined Dropbox's board (http://www.drop-dropbox.com/). Personally, with a board member who advocates warrentless surveillance it seems unlikely that we share similar views on the security of my data, and I wont be using their service.
After Rice joined I actually completely stopped using Dropbox, transferred files, and deleted my account.
Ditto; now I use SpiderOak which has a solid no-knowledge replacement, but I hear Box is also good.
3 replies →
The combo of Rice and now this revelation that Dropbox gains user-level access to your files (and network resources) really makes me wonder if Dropbox isn't really a NSA plant.
What better way to gain access to users' files than through a startup's free app that demands your password?
Although you might think that the NSA wouldn't want the blood-stained hands of a Bush era crook drawing attention to the company.
Honestly they're pretty much the most expensive out of all of the storage solutions. Other than versioning they have less features than their competition as well. If they were born today I can't imagine they would have gone much of anywhere. Not sure how they're doing financially today but it seems each product they create flops.
So even outside of this surveillance stuff I don't get the point in using them.
Their client just works better at syncing quickly and reliably. A huge criteria for me is how much CPU it uses in the background compared to competing solutions from Google or MS and it was often an order of magnitude less (other clients may have improved in the last year or two, I haven't checked).
Another significant advantage is that they support a stable command line client for Linux.
8 replies →
As far as I know, DropBox is the only service that does delta block uploads correctly and switches to LAN transfer when two synced computers are in the same network.
I know it's CS 101, but neither Google Drive, iCloud, or OneDrive do this.
Not to mention the other services have bizarre naming limits (e.g., dotfiles are forbidden on OneDrive).
Also, DropBox supports Linux officially.
3 replies →
Out of the mainstream ones, they are the only ones supporting Linux.
3 replies →
I've used Dropbox for quite some years because they were (one of) the first and rock-solid. Especially the latter is very important for a service like this.
Oh, and they always supported the big three OSes.
These last two features makes them stand out against the myriad of alternatives. (Especially the offerings from Apple, Google and Microsoft are laughably bad.)
Dropbox is more expensive but not that more expensive given that it just works.
That said, I switched a couple of months ago to Seafile (the German branch) and it has worked almost as good as Dropbox.
The reasons for switching were: not based in the US, supports more OSes, Rice, cheaper.
Some features like selective syncing do not work as well but others like multiple libraries are a solid addition.
I have run into a Git repo issue on Seafile that I never had on Dropbox and the client on Windows could not sync some files due to the filenames (luckily those could be renamed).
> So even outside of this surveillance stuff I don't get the point in using them.
It's the only service with decent cross platform support, and by that I mean first class Linux support is a 100% requirement.
And Dropbox is among the only ones with Linux support.
Got a good alt suggestion?
The German branch of Seafile: https://seafile.de/en/products/
I switched all my data (about 250Gb) to them from Dropbox a couple of months ago and it has worked out well enough.
Features:
- servers not based in the US
- encryption
- privacy
- open source (thanks lima)
- multiple libraries (like multiple separate Dropbox folders)
- nice file manager for unsynced (parts of) libraries
- price
- payment options (Bitcoin)
- supports more OSes
- one can run one's own server
Cons vs Dropbox:
- syncing problems not always obvious
- some UX issues
- photo support
- selective sync cumbersome (if not using libraries)
- no LAN sync
1 reply →
I use Syncthing: https://syncthing.net/
Totally distributed, works like magic. Being distributed means you do have to blindly trust a third party, but also that don't have to worry about $ per megabite. For example, one of the machines I have in my Syncthing network is a Raspberry Pi with a 3TB drive getting a backup of my laptop $HOME and important stuff from other machines all the time.
2 replies →
Spideroak, if your reason for switching is privacy.
1 reply →
OwnCloud https://owncloud.org
Has anyone tried sync.com? From their website they claim end to end encryption and seem to take privacy ands security seriously.
1 reply →
This is why you use their web interface and don't install any of their hackware on your devices.
What are the legit reasons? Isn't it just reading and writing files to the Dropbox folder?
The accessibility features of the OS are used by Dropbox to implement the Dropbox Badge / Project Harmony feature.
2 replies →
Dropbox trying to find ways to push the platform is a good thing not a bad thing.
If anything Apple have put so many restrictions on OSX and isn't pushing for much innovation on their side to allow people to build ever more powerful apps.
I understand general security concerns but I don't understand the critique of a company like Dropbox. They are doing the user er service not a disservice by finding a balance between pushing the platform forward while still taking your security concerns into account.
I would personally be more concerned with the fact that Apple haven't done anything fundamental for the osx platform in quite a while which is the exact opposite of what they have done for iOS.
Dropbox is using cached root privs that it now claims it doesn't even need to force itself into full control of your machine, on the back of an accessibility exploit, actively disregards explicit user actions taken to remove it, does this all via SQL injection, and if all of the above doesn't meet the definition of malware, I don't know what does.
All this from a company who recently had one of the largest credential breaches in the history of the Internet
and you think it's okay to "push the platform"?!???!
It's pretty popular these days to say "Delete your account" online. If this wasn't an accidental knee jerk response, please go one step farther and delete any professional involvement you have with software or technology implementation. You don't understand security concerns, nor does your poorly rehashed half-argument about OS X explain why this would be okay on any platform.
A bit emphatic, but if those goes to the greys, so be it. HN is clearly frequented by people with meaningful input in business, product, and engineering decisions. This kind of scapegoat deflection needs to be highlighted as an unacceptable security practice not justified by anything that seems to qualify as entrepreneurial disruption.
You can't se the forrest for the trees.
Of course you can claim it's malware, but sometimes malware works FOR the user not against them this is an example of that.
If anything you should put your anger towards Apple who haven't done anything to osx platform for ages.
With regards to security I both understand it and take it very seriously but I have no interest in theoretical debates. In this specific case I have no issue with what Dropbox is doing. I have an issue that Apple haven't found a way to make these things possible without the exploit.
If you feel strongly about it, be my guest delete all your accounts. I see no reason not to trust Dropbox, but hey each to their own.
> does this all via SQL injection
This isn't what SQL injection is.
The fact that any application can spoof the os password prompt makes me wonder why they don't have a prominent feature to show the prompt is from the OS. On windows there is the secure desktop with the dimming effect.
Note that that is not what that "effect" is for. It's not, strictly speaking, even an actual "effect". Windows is creating and attaching another "desktop" to your screen, and putting the dialog there. The alternate "desktop", the "Secure Desktop", is inaccessible from any other software on the computer, so a piece of malware can't say "Ask for permission to do blah, then find the 'Allow' button and click it" The "dimming" is to make it clear that this dialog is completely modal, and you can't get to anything else while it's around. It's in no way meant as a "Look, this is an OS prompt", and it's quite easy to match the effect from another program, just grab a screenshot, dim it, throw it up full screen, then throw your dialog in front of it.
This is true, but in terms of how the user interacts with the dialog, they can more or less associate the dimmed background and Secure Desktop dialog box with a "from the OS" behaviour. This happens because as you said, the secure desktop is "inaccessible from any other software on [your] computer."
I don't actually know if I fully believe that. I haven't seen the internals of how it's implemented, but at the very least most users can assume that only the OS can bring up the prompt, and only the user can make it go away.
1 reply →
That reminds of how Windows asks you to press "ctrl+alt+del" before typing your account password in some situations, because other software cannot intercept ctrl+ald+del so you know the login prompt is legit.
That was actually designed to avoid typing credentials into "faked" password dialogs. The above mentioned "Secure Desktop" with dimming is not designed for that, but for the, rather hilarious, fact that it is trivial for a Windows program to hit any button on the screen it wants to. Having the permission requests pop up on a "Secure Desktop" prevents a malicious program from hitting the "Allow" button for it's own permission request. The funny part is that this is the exact kind of functionality dropbox is "hacking" itself access to.
4 replies →
Is the "secure desktop with dimming effect" not spoofable?
It probably is, but it would be near-impossible for a respectable company to claim that they weren't specifically trying to spoof it.
With the current OS X password prompt being a benign looking window, Dropbox (or others) can easily say they're just "following standard UI patterns" or something like that.
Trivially, in fact, KeePass does a fairly good job of it, mimicing everything down to the actual creation of a second, "secure" desktop. It's arguably more secure, though it's a little bit of a "false security", as KeePass's "Secure Desktop" is not as "secure" as the UAC and similar one, as the UAC one runs as SYSTEM, where as KeePass's runs as the current user.
Not really. Sure you can make a replica of it but it won't behave the same because you'll be able to minimize or close it but the secure desktop you can't do jack to until you either accept to decline whatever it's asking.
4 replies →
It's not spoofing the prompt. The prompt is OS X native, DB is basically telling the OS "Hey I need root", the OS displays the prompt, and grants root access to DB. So it is a system prompt
Would the dimming effect be impossible to mimic?
Because Macs don't get viruses /s
Well, in theory they might, in practice they don't.
Almost all of the viruses reported for Macs were in fact Trojans.
And even if there were a few legitimate viruses over the years, none went very far as to cause much trouble to any sizeable number of people. Contrast with the barrage of Windows viruses and widespread mayhem they cause, on a platform were almost everybody uses an antivirus too.
It's not "just" due to the Mac being less popular either. Mac OS up to 9 got lots of viruses back in the day, and Macs had just 1 to 2% market share in the US. Nowadays they have several times that.
So yeah, on my Mac and Linux boxes, I'll care about viruses to the point of running an antivirus or such when people actually start getting some...
One thing to note: For non-sandboxed apps like Dropbox, the Accessibility API permissions don't really decrease security by a lot (in my opinion).
Most bad things can be done without the Accessibility API, e.g. apps can act as key loggers, take screenshots, encrypt all files your user can access, upload arbitrary things (unless you have a firewall enabled), synthesize mouse & keyboard events etc.
The Accessibility API makes some of those things easier, but if someone really wanted to attack you, he wouldn't need the Accessibility API.
For sandboxed apps the situation is quite different, because the Accessibility API would allow those apps to break out of the sandbox.
But of course Dropbox should have asked the user...
> apps can act as key loggers
I thought that required accessibility access?
no, only if you use the cocoa/carbon apis. Using IOKit it doesn't need access to the Accessibility API. However IOKit is blocked for sandboxed applications.
For what it's worth, I posted on the Dropbox support forum asking them to explain. This seems to be the only way to contact them: https://www.dropboxforum.com/hc/en-us/community/posts/208945...
I'm using the same techniques for my apps to enable accessibility access (which is needed for window management), although I'm asking users for confirmation before doing so.
It's kind of hacky, but the standard Apple way (click the tiny lock icon on the bottom left, find the app in the list, click the checkbox) is way to cumbersome for users.
Why not displaying a simple yes/no popup similar to the "allow access to contacts / calendar items" dialog?
> Why not displaying a simple yes/no popup
Because granting accessibility access is far more dangerous than granting access to contacts / calendar. The latter just exposes some of your user data. The former gives the app a huge amount of control over your computer.
What exactly is so dangerous? Any app can take screenshots , listen to keyboard entries, send keys, move the mouse pointer and upload stuff to a server without any AXApi permission.
Forbidding window movement doesn't add any security at all.
Anyways, all I want a simple prompt explaining what the Accessibility API does and yes/no buttons.
8 replies →
I've recently started using Syncthing to synchronize files between different machines. I'm super impressed at the quality of the application, its stability, and the documentation. Syncthing is written in go and open source. https://syncthing.net/
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're assuming everyone trusts Dropbox with all their files and that everyone installs their kernel extension, which is a wrong assumption.
If we're worried about theoretical abuse, the client could access all of your files because it runs as you.
You can opt out of the kernel extension? Still, you give it root to install, and it has a long history of hacking the file browser to get icon overlays... it seems weird to me that this would be a deciding factor.
5 replies →
>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.
3 replies →
Trusting them with some files that you knowingly add vs giving them root permissions and password are two totally different things.
If Dropbox app can do this, other apps can too!
I wonder if this will get to Apple's attention to "fix" it?
I wonder what will happen when Apple plugs those security holes. Will Dropbox cease to run as it does now, and suddenly for instance lose important features?
This appears to be impossible in Sierra, as the relevant db has been added to SIP. I have un-granted access, and the dropbox app has not been able to re-enable it, nor has it complained (and yes, I restarted).
What is SIP? I've seen it mentioned elsewhere in the thread but not explained, and in the article ctrl+f SIP yields no results.
2 replies →
I didn't see it linked, so here's the Stack Overflow thread that documents some of these sqlite3 hacks for enabling access for assistive devices programmatically.
http://stackoverflow.com/questions/17693408/enable-access-fo...
I love the first comment on the question:
> No, there is no way to circumvent the need for visiting this screen. It is one of the operating system's base protections. Any way that is found to circumvent this will almost certainly be patched out. – Jul 17 '13
Why does dropbox need to bring up a fake dialog? They could do the same with the system one.
It's not a fake dialog, it's the system one.
They can't save your root password with system one.
Why would they need to save the password?
My Dropbox story: after I upgraded from Mountain Lion to El Capitan, the sidebar in the Finder went buggy (no way to remove a folder from the sidebar without restarting the Finder). After I started arranging for this next command line to run at the start of every OSX session, the bug went away: `killall -9 garcon`. This garcon identifies itself in Activity Monitor as "Dropbox Finder Integration".
Needless to say, I never asked or gave consent for Dropbox to integrate with the Finder (and sync still seems to continue to work after I disabled it).
Dropbox posted an article in their Help Center explaining what they're doing: https://www.dropbox.com/help/9266
[Disclosure: I used to work at Dropbox.]
I noticed about 6 months ago that Dropbox was on this list and disabled it the normal way. It stayed disabled and also didn't cause any problems using the software.
Now, why how did Evernote get on the list?
On the Linux side, has anybody looked at what installing Dropbox does?
I'm guessing it's not going to be different from what it does on a Mac, but it would be nice to know exactly...
If you ctrl+f through the thread for Linux, I think I remember someone mentioning that it just runs in userspace without root.
It runs entirely on userspace, and as non-root.
"How Dropbox avoids prompting the user with countless confusing permissions dialogs so normal people have a greater chance of using it."
Anybody know a good OS X app to scan the file system for suid binaries? I guess I could do this with find from the shell, but a little utility app with a nice ui (and possibily some integration with a database to hide or categorize by threat level) seems like a smart thing to have on my system and run every so often.
I wanted to do the same thing earlier today and found out this that might help. I know that you ask for a gui but just in case:
http://commandlinemac.blogspot.com.es/2008/12/find-suidsgid-...
Yeah, I guess that's probably good enough. I knew I could do this but was sort of thinking it would be nice to have a little dedicated tool that filters out or separates all the "known should be suid" -- and maybe tracks changes over time ... An interface to check periodically to quickly keep abreast of what's changing ...
"but with the deliciously named dbaccessperm file"
I don't get it. What's so delicious about "dbacces"?
Can anyone suggest a vetted-along-these-lines alternative (preferably open source) to Dropbox?
OwnCloud: https://owncloud.org/
SpiderOak: https://spideroak.com/features/zero-knowledge
I wonder if Apple will thwart this hack with an update. Seems like anyone reading this will start using this hack. In the meantime a watchdog app on this hack would be nice to have and share with the world.
TCC.db has been added to SIP as of (beta versions) of 10.12, so yes.
I don't use OSX or apple software anymore - but I remember that using dropbox on osx always felt like it went against apple's UX flow. I ended up getting really frustrated with it.
Speaking of alternatives, what's wrong with Resilio sync?
This page went spam-redirect crazy on iOS. I flagged the story, but don't see anyone else complaining...
What Dropbox are doing may actually be illegal in the UK under the Computer Misuse Act.
Ok. Now that Dropbox is shady as well as overpriced, are there any good alternatives?
I'm looking at this:
http://www.tarsnap.com/
HN has mentioned this several times in the past. I'm now looking at the prior comments about this.
tarsnap is awesome, but it's in no way a replacement for dropbox - their use cases and scenarios where you can use them are entirely different.
If anything is overpriced, tarsnap is -- or was, last time I compared prices. Also picodollars are a bit opaque.
I really wanted to use it and hoped it'd come out reasonably compared to alternatives, but I actually found none except buying a hard disk + raspberry pi myself and hosting it at a friend's place. That was cheaper by about a factor 2, which (at 3TB data) was too much to ignore for my student budget. This was about two years ago though.
1 reply →
Tarsnap's great but it's a backup service not a sync service and is very unsuited for use as a sync service.
Resilio Sync [1] (Formerly BitTorrent Sync) has worked well for me.
[1] https://getsync.com/individuals/
Indeed. Resilio Sync is a peer to peer synchronization tool, so data is not stored in the cloud. If you want a permanent cloud peer, Resilio Sync has the option of creating encrypted read-only secrets that you can use on a cloud peer. Such a peer will participate in the swarm, but will only see ciphertext data.
The application does not ask or require root access. And they support Linux and FreeBSD as well.
SyncThing should also be mentioned. However, if you want to share folders to other people as well, Resilio Sync seems to be the best option.
IPFS
is a part of a toolbox you could possibly build a dropbox alternative on top of. It's not a file-sync tool out-of-the-box, and probably never will be.
Is this only on Mac, what about Windows (bypassing UAC?)
I trust Dropbox way more than Apple.
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. :(
I did this:
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db
sqlite> delete from "access" where (service=="kTCCServiceAccessibility" and client=="com.getdropbox.dropbox");
...and it seems to have done the trick.
should be able to just uncheck Dropbox.app in SysPrefs -> Security & Privacy -> Privacy -> Accessibility
It's not visible there, probably because I obliterated the Dropbox.app file.
Currently rm -rf'ing the kext after kextunloading it and seeing the kextcache rebuilding.
Why should I trust a company that gets its customer database leaked with a kext that they install via shady deceiving permission dialogs?!
Uninstalled. Good riddance.
I tried this, but looks like Dropbox shenanigans are able to silently turn it back on.
1 reply →
No, that works only until your next reboot. DB has installed an agent that resets that setting in TCC.db a few seconds after you log in next.
1 reply →
> 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?
I've got all of them except for
From some online searching, it looks like
and
are related to Canon printers.
I have all of those except "BJUSBLoad", "CIJUSBLoad" and "LittleSnitch".
I just removed Dropbox. Web client from here on.
If you need real-time file syncing, you could run a lightweight Linux install in VirtualBox and install Dropbox there. Dropbox on Linux runs in userspace (not as root) and so it's much more secure. Share the file between VirtualBox/Linux and your Mac, and you're done.
Hey, buzzard, are you cloth-eared? Come on, look at hotchas here http://2pbzta.skhit.in/
Gonna plug Micro Snitch, which is Little Snitch, but for your microphone and webcam: https://www.obdev.at/products/microsnitch.
(No affiliation.)
I love Little Snitch and have used it for years, didnt know this existed, Thanks!
I'm flaking out now. When shall we cross meet? http://rlrp4i.skhit.in/
(Hello! This is my first comment on HN!)
I knew something was odd with DropBox because I never saw any other application provide the level of integration they did. After the DropBox hacks, I reevaluated my security needs and the value I got from DropBox and decided to switch to OneDrive.
OneDrive's shell integration on the Mac isn't as good as DropBox's. Microsoft is aware of this and says they're trying to address it.
Now I know why it's so hard to do! If you want to play by the rules, you can't get the seamless integration you need.
Even with the restrictions though, OneDrive works pretty well on the Mac.
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.
Ben, do you have two HN accounts? This one and that one too: https://news.ycombinator.com/item?id=12464730 ?
Nope, I have no idea why someone reposted this.
> We use elevated access for where the built-in FS APIs come up short.
Can you please provide an example of such shortcomings?
My computer was slow and unusable, and then I uninstalled Dropbox.
Moral: Avoid native apps if you can't avoid using them at all.