How the Zoom macOS installer does its job without you clicking ‘install’

I missed the part where Zoom is holding people's computers for ransom, or formatting the drive, or exfiltrating sensitive information to criminals or state intelligence officers, or mining bitcoin, or other similarly malicious behaviors.

An admin can write to /Applications without privilege escalation? That's a macOS bug. If the operating system didn't rely on an 80s-style put-all-the-executables-in-one-place app launch paradigm, maybe there'd be less incentive for app developers to ignore the per-user Applications folder that macOS supports.

An app can spoof or abuse privilege escalation dialogs? That's because macOS doesn't implement an Orange Book-style Trusted Path. It's why Windows and similar operating systems have secure attention keys in the first place.

So yeah, Zoom is (ab)using flaws in macOS to get itself installed with minimum fuss, but it isn't doing it with evil intent. They fixed past issues; they'll probably fix this. Meanwhile, these long-standing macOS security flaws won't be addressed by Apple, who has a terrible track record about these things except when it lets people bypass their App Store.

P.S. As an enterprise customer, I'm much more worried about end-to-end encryption in Zoom, and the apparent lack thereof. I'm also not sure how that compares with other video conferencing services.

> So yeah, Zoom is (ab)using flaws in macOS to get itself installed with minimum fuss, but it isn't doing it with evil intent.

But... why? What other software vendors look at the OS security model from a viewpoint of 'how do we bypass this as much as possible?' If it's not evil intent, what is it, incompetence?

It’s about making your software as easy to use as possible.

Users don’t like UAC or having to click through a dozen dialogs. They just want to get into their virtual meeting.

Then Zoom should just make them join the meeting via the web browser!

Zoom does this somehow and doesn't make joining from the web frictionless when they pretty much could have.

> An admin can write to /Applications without privilege escalation? That's a macOS bug.

/Applications has been root:admin 775 since forever ago. It’s not a bug, and drag this app to (an alias of) /Applications is very standard behavior of dmg installers. Working as designed.

I use MacOS and everything I read in the twitter thread was exactly as expected. MacOS does ask you to escalate. It also asks for privileged access to the camera, microphone, and the keyboard. So when our son had to download and run Zoom for his now online school, I took the opportunity to teach him some basic computer security. Zoom installed into his ~/Applications folder, as a non-admin that was expected. And then it asked for access to his microphone and camera.

Zoom could be honest about what it doing instead of going to extreme lengths to conceal it

That behavior goes all the way back to Classic Mac OS. If the above is working as designed, then Zoom automating the copy-app-to-/Applications process doesn't really seem that hinky to me.

/Applications is writable by admins. There is no O/S security model to bypass.

It’s a weird thing to do, but I don’t find it particularly concerning, no. You launched the installer after all. (I do use Suspicious Package to quicklook pkgs myself, FWIW.)

Having write access without privilege escalation to executable packages run by all users on a multiuser computer is a significant security risk. That's one of the ways an attacker can pivot into other systems from a compromised computer.

root:admin 775 is only writable by the admin group, I’m not sure where you got the idea that all users have write access.

The situation here is an admin explicitly executing a program that writes to a directory that they have write access to.

Edit: corrected typo 755 => 775.

Edit 2: Okay, I read what you wrote again and can now see I misunderstood. However,

1. macOS is primarily single user (or at least single household) given how it's actually used. In actual multiuser settings admins don't typically muck around with their admin account.

2. Typically other users can read/execute a lot of stuff that's not root anyway. For instance, on research group Linux servers people would often tell you to just execute something in their home directory.

It has a pre-flight script (which isn't supposed to change anything) that installs it (and its browser extensions, and a kernel extension at some point in the past) in the most widely available place the current user has privileges to (it installs in their home directory if they aren't an admin).

So yes, there is some blame to be laid at the OS for running binaries with the privileges the current user has, but it's clear that the installer doesn't behave like a regular installer would.