Dropbox Responds to Mac 'Security Risk' Accusations [Updated]

[canadianreader]

Since they appointed Condolezza Rice on their board things gone a little out of hands. Fox in hen house.
You can use the browser's drag drop feature and avoid installing it on your mac.

 

[CarlJ]

As far as I know, this is only possible if it has the same access privileges as an Administrator or Super User.

So what I'm saying is that in my opinion, Dropbox really does cache the password and uses it to gain access to root and this thing goes all the way back to number one: in order to cache the password, they must have access to it right? So in order to get the password they spoof the permissions dialog.

Dropbox, just like a number of other programs that need persistent access to system resources, has the OS ask once for your permission to run a program with admin access, then uses that access to endow a helper program with permanent elevated access. In Unix, this is called a SetUID program. It's achieved using "chown root /path/to/program; chmod 4755 /path/to/program" or the system call equivalents. They don't need to cache a password, because you have authorized their helper program to have permanent root-level access. This is a common practice for programs that need such access, and has been for a long time - Unix programs have been doing this for decades. Since long before OS X existed. Concentrating the bits of the code that actually need root-level access into a small helper program is actually a security improvement, over making the entire app run with root-level access. The whole bit in the video about "but I haven't unlocked the padlock" was laughable - the guy doesn't understand how Unix permissions work. Should Dropbox explain why they need the Accessibility access? Sure. But this isn't any sort of hack.

You're certainly entitled to have your opinion, but you're still just flat-out wrong. They're not caching the password, they're not spoofing, you - and the site you're parroting - simply don't understand how Unix works, and your constructing an elaborate scaffolding on top of your misunderstanding. Please stop spewing misinformation. Trust Dropbox, or don't. But understand how the operating system works.

 

[jonnysods]

Don't say bad things about Dropbox, they've been so kind to me, and so helpful to my business!

 

[canadianreader]

I'm not trying to defend Dropbox, I'm just trying to point out that your argument "I don't KNOW FOR SURE what it does so it COULD DO ANYTHING" applies to basically any Mac app. So if that's your biggest issue with this, maybe you should stick to closed systems like iOS.

Some of us have what we call suspicions and can make us uncomfortable so we jump to conclusions or we start to defend or generalize to feel better. This is not any other app this is millions of computers that are at risk of being spied on and no one knows the motives of dropbox for not specifying in the password dialogue box that they want to access to Accessibility. Helplessness is a choice

 

[AppleInLVX]

This is what you have to do besides unchecking the box, because you're correct, Dropbox will still work without Accessibility permissions:

Wow, that's pretty annoying. I hope the fix really does come "soon".

 

[Mackker]

Dropbox, just like a number of other programs that need persistent access to system resources, has the OS ask once for your permission to run a program with admin access, then uses that access to endow a helper program with permanent elevated access. In Unix, this is called a SetUID program. It's achieved using "chown root /path/to/program; chmod 4755 /path/to/program" or the system call equivalents. They don't need to cache a password, because you have authorized their helper program to have permanent root-level access. This is a common practice for programs that need such access, and has been for a long time - Unix programs have been doing this for decades. Since long before OS X existed. Concentrating the bits of the code that actually need root-level access into a small helper program is actually a security improvement, over making the entire app run with root-level access. The whole bit in the video about "but I haven't unlocked the padlock" was laughable - the guy doesn't understand how Unix permissions work. Should Dropbox explain why they need the Accessibility access? Sure. But this isn't any sort of hack.

You're certainly entitled to have your opinion, but you're still just flat-out wrong. They're not caching the password, they're not spoofing, you - and the site you're parroting - simply don't understand how Unix works, and your constructing an elaborate scaffolding on top of your misunderstanding. Please stop spewing misinformation. Trust Dropbox, or don't. But understand how the operating system works.

Thanks for sharing. However could you please explain why wouldn't be the case for Db to do the same things described in this article: http://www.symantec.com/connect/blogs/mac-os-x-dialog-box-spoofing-believe-me-i-m-system-preferences ?

 

[Tech198]

Except, if you read the blog, it's inherently clear that Dropbox spoofed the Apple password dialogue box. So they're still not owning up to it. They say it's an Apple OSX box thing, and while it's probably true that Dropbox doesn't see or capture the password you enter, it remains clear that the dialogue box is not really an Apple one.

You cannot spoof that Apple dialog authentication unless perhaps u were running as root.... how did u come to this conclusion? Even Apple themselves admit this is not possible. you can add u'r own icon overlay in addition, but that's not a spoof..

Even if there are stuff in the accessibility install from apps in order to aces u still need to provide password,, and of u don't the app is denied.... from whatever it may be wnating,, so i would say just the fact u must enter a password alone, is secure in itself.

 

[Sheza]

You cannot spoof that Apple dialog authentication unless perhaps u were running as root.... how did u come to this conclusion? Even Apple themselves admit this is not possible. you can add u'r own icon overlay in addition, but that's not a spoof..

Even if there are stuff in the accessibility install from apps in order to aces u still need to provide password,, and of u don't the app is denied.... from whatever it may be wnating,, so i would say just the fact u must enter a password alone, is secure in itself.

Again, it's not a spoof box, it's a box that is not being truthful and forthright about what it is asking you for. It's asking for a password so that it can add itself to the accessibility items. But instead of popping up the accessibility request box, which most apps use, it's just asking for a password so 'Dropbox can work properly'. The blog post explains in detail that this is far from the standard procedure and requires a lot of code wizardry.

 

[CarlJ]

Thanks for sharing. However could you please explain why wouldn't be the case for Db to do the same things described in this article: http://www.symantec.com/connect/blogs/mac-os-x-dialog-box-spoofing-believe-me-i-m-system-preferences ?

If you're asking, "but couldn't Dropbox have put up a fake dialog box?", the answer is yes, sure, they (probably) could have put up a fake dialog box. But what would be the point? They can put up a REAL dialog box, and have you authorize their SetUID helper program to run, and get the access they need to make the app integrate into the system. There's utterly no benefit to them to put up a fake password prompt, since they can use a real one, and there's a HUGE potential backlash if word of it ever got out.

Unfortunately, now, due to some idiots who have too little understanding of how the operating system works, and too much desire to unearth nonexistent conspiracies (or are maybe just in too much hurry to make a name for themselves), Dropbox has to deal with that backlash even though they haven't done anything wrong (they could have made their prompts more explicit, sure, but one of their big selling points is that the system "just works", with absolutely minimal fuss).

 

[dmdev]

At least Dropbox has responded, but unless they remove the constant request for Accessibility permission I will not re-install.

 

[loby]

OK, so what's the solution for us comparable Luddites? If I'm reading all this right, the issue lies with granting Dropbox access to Accessibility features. Furthermore, it seems like Dropbox works without this access. So the solution is to deny that access. But if you do, Dropbox reinstates it without a by-your-leave. Is that right?

So my question is, short of simply jumping ship on Dropbox (which is hard to do given that a considerable number of applications I use sync to Dropbox, and not to iCloud), is there a way to work it so that Dropbox is denied access to Accessibility and yet still functions?

Or have I got this whole thing wrong?

I too noticed this sometime back and was wondering why if you hit "cancel" when it asks for permission and your password that it continues to function without any seen limitation.

Note: If you deny permission when the dialog box appears, dropbox still performs as it should, but every time you boot up again, it asks for permission.

Question: Why do they need access and your password if the program functions properly without entering in the requested information?

As probably everyone who uses dropbox does eventually enter their password to get rid of the dialog box....

So "why" do they need permissions if the app works without giving permissions?

The problem with this article is "if" dropbox is not doing anything malicious....the damage has already been done...

Hmm...

 

[Nuvi]

So long Dropbox. You're so gone from all of my systems. Dropbox and Evernote are both on downward spiral...

 

[Peter Maurer]

Can someone explain to me why this is an issue?

For one thing, they're getting their accessibility permissions the wrong way. The correct way to make your process a trusted accessibility client is by calling AXIsProcessTrustedWithOptions(), which shows the user a dialog first, then takes them to the appropriate section of System Preferences, where they'll have to check that checkbox themselves for the app in question.

That's arguably tedious, but it's the way things are, and it mirrors Apple's penchant for making users show intent before giving an app the kind of power that trusted accessibility clients have (e.g., logging keystrokes).

So regardless of whether they _need_ to be a trusted accessibility client (as far as I know, they only do if you use their Microsoft Office "badge" feature), there is zero doubt that they are gaining that privilege the wrong way:

1. They make themselves a trusted accessibility client without ever telling you.
2. They do it by editing a system database that isn't supposed to be edited by non-system processes. (The database's structure isn't documented; it could change at any time.)

Everybody's definition of a hack differs, but I would indeed tend to call this a hack.

(Disclosure: I write Mac apps for a living, and two of of our products are trusted accessibility clients. Needless to say, we use AXIsProcessTrustedWithOptions() like any upright Mac developer would.)

 

[Mackker]

If you're asking, "but couldn't Dropbox have put up a fake dialog box?", the answer is yes, sure, they could have put up a fake dialog box. But what would be the point? They can put up a REAL dialog box, and have you authorize their SetUID helper program to run, and get the access they need to make the app integrate into the system. There's utterly no benefit to them to put up a fake password prompt, since they can use a real one, and there's a HUGE potential backlash if word of it ever got out.

Unfortunately, now, due to some idiots who have too little understanding of how the operating system works, and too much desire to unearth nonexistent conspiracies (or are maybe just in too much hurry to make a name for themselves), Dropbox has to deal with that backlash even though they haven't done anything wrong (they could have made their prompts more explicit, sure, but one of their big selling points is that the system "just works", with absolutely minimal fuss).

OK, thanks for replying but I'd like to make some things very clear:
1. Calling names won't give you any benefit, on the contrary.
2. Dropbox may or may not spoof the permissions dialog but the way they handle security is very suspicious to say the least. By not informing the user of what privileges they want to have access to (which, from what I've understood are not needed) and the fact that their agent re-enables or re-adds itself after being disabled/deleted gives me and others all the reasons not to trust them.

I don't think you can argue with the fact that Dropbox app for OSX behaves just like a Trojan.

 

[CarlJ]

That's arguably tedious, but it's the way things are, and it mirrors Apple's penchant for making users show intent before giving an app the kind of power that trusted accessibility clients have (e.g., logging keystrokes)..

It's what they should have been doing. If anything, I'd guess the reasons their code isn't that way, is a combination of cross-platform code (or mindset), and old code. I suspect some of the related code predates some of the more fine-grained permissions controls in OS X.

The problem with calling it a hack, is that for most non-programmers that will simply reinforce the idea that there was nefarious intent, and there's already enough torches and pitchforks in play here for no good reason. I highly doubt their intent was malicious. They were just a bit sloppy. Now the conspiracy theorists are having a field day, chomping on this tenaciously and proclaiming victory over the evil imagined oppressors, and congratulating each other for uninstalling Dropbox, when they simply don't understand (but they're not going to let facts get in the way of them shouting - wrongly - "caught you red handed!").

Spock isn't the devil, his heart is just in a different place than humans (bonus points for the few that get that).

 

[Peter Maurer]

I highly doubt their intent was malicious. They were just a bit sloppy.

I'd tend to agree. If I were them, I'd fix this and move to the proper API as soon as possible.

But even then, this episode will probably have a lasting effect on how I use Dropbox — after all, their sloppiness and their unwillingness to own it can become even more dangerous with their kernel-extension-based Project Infinite.

 

[CarlJ]

OK, thanks for replying but I'd like to make some things very clear:
1. Calling names won't give you any benefit, on the contrary.

Sorry, I used the term "idiot", which OS X's dictionary defines as "(noun) a stupid person"; they further define "stupid" as "(adjective) lacking intelligence or common sense". It seemed like useful shorthand and a fitting description of the folks pushing this nonsense, but I'll try to refrain from using it here in the future. I'll take it then that you have no problem with my characterization of them as having "too little understanding of how the operating system works, and too much desire to unearth nonexistent conspiracies (or are maybe just in too much hurry to make a name for themselves)."

But apparently it's okay for you to go about claiming that people are PURE EVIL when you don't have any facts to back it up.

2. Dropbox may or may not spoof the permissions dialog but the way they handle security is very suspicious to say the least.

Dropbox is NOT spoofing the permissions dialog box. People like to jump to hasty conclusions and see demons besetting them at every turn. The problem is, these things get out of hand.

Remember a while back when an obscure security check in the iPhone's software broke some phones when they updated to a new OS release? It was something they didn't expect would ever get triggered unless someone (like a government) was trying to break into the phone's security hardware, so it just locked up. Turned out it got triggered by third-party repair places swapping out the TouchID sensor improperly. But when it got triggered, suddenly the "Apple is evil" crowd was completely convinced that Apple did this entirely on purpose specifically to screw the little repair shops, in order to drive them out of business. (The truth is Apple likely doesn't spend more than about ten seconds a month thinking about third-party repair places, they're just not really on the radar - certainly not enough to go about concocting elaborate plots to make them look bad.)

Bad things generally happen when you go looking for and expecting malicious intent when the reality is things simply go wrong. Hanlon's razor states, "Never attribute to malice that which is adequately explained by stupidity." That holds up pretty well.

By not informing the user of what privileges they want to have access to (which, from what I've understood are not needed) and the fact that their agent re-enables or re-adds itself after being disabled/deleted gives me and others all the reasons not to trust them.

The former (not informing exactly which privileges they need) is likely explained by a combination of, their setup code originating before some of the later finer-grained privilege mechanisms in OS X came into being, along with wanting their "user on-boarding experience" to be quick and simple. A little sloppy, perhaps, but not nefarious. The latter part (the agent re-adding itself to Accessibility, the seemingly shocking thing the blogger discovered, is likely the Dropbox software simply repairing what it interprets as damage. It isn't designed to have an ongoing pleasant AI-based conversation with the user about what percentage of the software you would like to have work, it's just trying to do its job, and found that something it had initially set up, in order to do the task it was installed to do, was now broken.

And not liking the same flavor of ice cream as you would "give you reasons not to trust them" if you want it to. You can distrust them for being too tall, for all anybody cares. That's different from having valid, fact-based reasons not to trust them. But go ahead and distrust them all you want. It'd be nice, though, if you'd stop the campaign of misinformation, to keep others from mistakenly following you down this unfortunate path.

I don't think you can argue with the fact that Dropbox app for OSX behaves just like a Trojan.

Oh, I absolutely can argue with that. The difference between a vaccine and a disease is intent. One is a good thing, the other is a bad thing. A vaccine is similar to a disease, because they're made of the same stuff. Would you claim that a "vaccine behaves just like a disease"? No, not unless you're being disingenuous, because you know that vaccines protect us, and diseases hurt us. Dropbox on OS X does a lot of behind-the-scenes things on OS X, because that's what it takes to get its (good, useful, and helpful) job done. It's there on my system because I wanted it and installed it, knowing the consequences and the ramifications of the kinds of permissions I was granting it. A Trojan, on the other hand, is an unwanted invader, designed to do nefarious things. It also does a lot of behind-the-scenes things on OS X, to get its evil job done. If I had any on my system, they would be there because they had snuck onto the system somehow, against my wishes. I can't quite tell from your last statement if you're trying to conflate the two, or if you really don't understand this distinction between good and bad intents.

 

[Peter Maurer]

It's there on my system because I wanted it and installed it, knowing the consequences and the ramifications of the kinds of permissions I was granting it.

Ah, so that's the difference between us: When I gave Dropbox my admin password, I didn't expect the accessibility thing. Not. At. All.

Again, I'm not saying that there was malicious intent. And I don't necessarily object to giving Dropbox accessibility privileges if they're up-front about it. But the current implementation is still malware-like behavior in my book, just like a live vaccine is still a virus. Maybe that's what Maccker meant to say.

 

[beanbaguk]

I've just dumped Dropbox for Google Drive. I wonder if they do the same.....no. They don't.

Google Drive is your friend

 

[maflynn]

I've been weening myself off of dropbox, I think its time, to avoid this app, given the security risks it exposes on my system

 

[PinkyMacGodess]

Except, if you read the blog, it's inherently clear that Dropbox spoofed the Apple password dialogue box. So they're still not owning up to it. They say it's an Apple OSX box thing, and while it's probably true that Dropbox doesn't see or capture the password you enter, it remains clear that the dialogue box is not really an Apple one.

My understanding is this is a box to allow for files to be written in 'controlled areas' of the harddrive. They aren't 'hacking the OS', but putting files in protected folders. So many installs require you to enter your password, I don't think every install is grabbing your password, I don't think it's even possible for an install to grab your password as this is a system function.

It's perhaps ill advised to cook your own password request, given that many people are so sensitive, and rightly so, about securing their systems. Hooking up their software for their service to be able to be used in so many applications is going to require some serious magic. It doesn't mean they are up to 'no good'...
[doublepost=1473769089][/doublepost]

I've been weening myself off of dropbox, I think its time, to avoid this app, given the security risks it exposes on my system

I just wonder, then, how many other apps are assuming too much control.

 

[maflynn]

I just wonder, then, how many other apps are assuming too much control.

Open up your system preferences, select security and privacy and then the privacy tab. You'll see the apps that have been authorized to take control

 

[displaced]

It seems to me the issue is twofold:

• Dropbox are using an undocumented method to set itself as an allowed Accessibility application.
• Dropbox does not explain why it needs this set.

The password prompt appears to be completely in keeping with Apple's suggested practices for apps to install background 'superuser' processes.

One point of interest that I want to check when I'm back at my Mac is how this background helper is implemented. Personally, I'd expect it not to use the suid bit. Instead, when the user is asked for their password, it should use an elevated process to install a launchd agent definition which causes launchd itself to execute the helper with the desired user level. This seems more appropriate to me, since the agent definition can specify many kinds of process-related info, such as what action to take if the process crashes, resource limits for it, etc.

[EDIT: Scrap that last paragraph. The fact that if you decline to provide your password, you'll be prompted at each reboot suggests that the helper tool is not running as a privileged process, so launchd's ability to run it as such isn't needed. So the password prompt is probably exclusively to enable this undocumented method of modifying the Accessibility settings.

So that's kinda good, in that the background process isn't running with more permissions than it needs, at least. The 'naughty' method of changing the Accessibility settings is a bit cheeky though. Nothing particularly scary. My main interest is in why dropbox needs that access.]

 

[PinkyMacGodess]

Open up your system preferences, select security and privacy and then the privacy tab. You'll see the apps that have been authorized to take control

It was more of a rhetorical question, but thanks for the info. I'll check my macs and see what, if anything , has snuck in there...

 

[997440]

For one thing, they're getting their accessibility permissions the wrong way. The correct way to make your process a trusted accessibility client is by calling AXIsProcessTrustedWithOptions(), which shows the user a dialog first, then takes them to the appropriate section of System Preferences, where they'll have to check that checkbox themselves for the app in question.

That's arguably tedious, but it's the way things are, and it mirrors Apple's penchant for making users show intent before giving an app the kind of power that trusted accessibility clients have (e.g., logging keystrokes).

So regardless of whether they _need_ to be a trusted accessibility client (as far as I know, they only do if you use their Microsoft Office "badge" feature), there is zero doubt that they are gaining that privilege the wrong way:

1. They make themselves a trusted accessibility client without ever telling you.
2. They do it by editing a system database that isn't supposed to be edited by non-system processes. (The database's structure isn't documented; it could change at any time.)

Everybody's definition of a hack differs, but I would indeed tend to call this a hack.

(Disclosure: I write Mac apps for a living, and two of of our products are trusted accessibility clients. Needless to say, we use AXIsProcessTrustedWithOptions() like any upright Mac developer would.)

I agree with what you've said here and I have a question from an OS security perspective.

Your explanation concerning the OS notification prompt about accessing increased privileges through the accessibility pathway is confirmed HERE, at Apple support. Within that kb document, caution about granting access is rightfully highlighted and advised.

Considering this, why does Apple allow the alternate path of escalation that DB used?

[Edited to add link that didn't make it through.]