Friday, April 10, 2020

Zoom Installation

Felix Seele (Hacker News):

Ever wondered how the @zoom_us macOS installer does it’s job without you ever clicking install? Turns out they (ab)use preinstallation scripts, manually unpack the app using a bundled 7zip and install it to /Applications if the current user is in the admin group (no root needed).

Cabel Sasser:

The true Zoom experience begins with the installer. You have the standard list of steps on the left. The sheet comes down that says “This package will run a program to determine if the software can be installed.” You click Continue. The installer quits. It’s done. WTFFFFF

Kyle Howells:

This, and every Zoom controversy, makes sense if you think of it this way. They value easy of use above all else. Above being a good platform citizen, above security, above everything.

Like most start ups maximise engagement and growth above all, Zoom maximises ease of use.

Eric Slivka:

Zoom CEO Eric Yuan responded to Seele, noting that while the installation method was “implemented to balance the number of clicks given the limitations of the standard technology,” he recognized the issue and promised to “continue to improve.”

Zoom has now updated its Mac app installer to no longer use the preflight installation method, instead using a traditional installation authorization process, as noted by The Verge.

mmastrac:

I noticed while installing WebEx today that the installer immediately terminated itself after popping up the pre-installation script.

Running strings on the installation plugin (CWSPkgPlugin.bundle) shows why - it’s using a similar process to what Zoom does

Oliver Hunt:

Ok, so given sandboxing exists, I feel it should be possible to make it so that installers can’t write to the file system (or poll the network) while the preinstall scripts are running[…]

Cabel Sasser:

One thing that freaks me out about Zoom is that there are no Retina images on first launch, but later they just kind of… appear. I do wonder if they’re not there in the first place because of this “Reitna” typo

Charlie Fish:

Is there ANY legit reason why @zoom_us needs admin privileges to support retina display on macOS? Never seen an application require admin privileges to use retina display.

Guilherme Rambo:

The initial download of the app doesn’t include retina assets, so they have to be downloaded and installed separately (why that requires admin privileges, I don’t know). Yet another “feature” they implemented without thinking about the implications.

Dan Amodio (Hacker News):

zoomAutenticationTool will run whatever script you give it, and ask you to authenticate as System. It’s like they wrote their own sudo tool.. Don’t think you can weaponize but weird practice.

Previously:

Update (2020-11-27): Pedro José Pereira Vieito:

Introducing InstaZoom: A Safari Extension that transparently redirects Zoom meeting links to Zoom in-browser web client so you can avoid installing the Zoom application.

3 Comments RSS · Twitter

That reinforces my belief in using a normal account without admin privileges on my Macs, and refusing to install Zoom outside iOS. That said, if security can be circumvented so easily, it's a critical macOS security bug that is Apple's responsibility to fix.

@Fazal

"That said, if security can be circumvented so easily, it's a critical macOS security bug that is Apple's responsibility to fix."

It's not a security issue. It's a UX/user issue. Installer.app tells you:

"This package will run a program to determine if the software can be installed."
"To keep your computer secure, you should only run programs or install software from a trusted source. If you're not sure about this software’s source, click Cancel to stop the program and the installation."

It's not Apple or Zoom that clicks on the Continue button. It's you after being informed that a program will be run.

It could be said that the message is unclear. But it has been unclear for years. It also appears for Installer Plugins which do not determine if the software can be installed (most of the time).

Also the script is run as the current user. So if you're an admin, yes, it can copy files in /Applications.

If you're not an admin, it asks you to authenticate as one. Then again, it's you who's typing the password after being invited by an (unexpected) system authentication dialog.

Oliver:

"Ok, so given sandboxing exists, I feel it should be possible to make it so that installers can’t write to the file system (or poll the network) while the preinstall scripts are running[…]"

Not a good idea.

- requirements scripts are run as the current user. So they can't do any more harm than any other application.
- distributions/flat packages can/have to be signed too and can be notarized. (and for notarizations, the Installer plugins now have to be codesigned too).
- only pre-installation and post-installation scripts can be run as the system user but you have to authenticate as an admin.

Why should there be a difference between installation scripts and non-sandboxed apps?

It's very common to have Installation packages that have an empty payload and just run scripts. It's an easy way to provide a somehow human friendly solution to be able to run a script as root.

Also being able to read/write files from installation scripts is definitely a requirement. For instance, due to the lack of solutions to securely communicate between Installer plugin/Installer JavaScript code/installation scripts, you quite often end up using intermediary files to communicate between these components.

If you prevent an installation script to read/write files as the current user or the system user (if authenticated as an admin), what is the next step? Prevent an installation script from loading/unloaded a launchd agent, opening an application?

Sören Nils Kuklau

It's never been that clear to me what the "This package will run a program to determine if the software can be installed" dialog is asking me. Are packages that don't run such a program safer? Is there something the package author did wrong? Will this practice be deprecated altogether?

If a program doesn't use an installer, but instead uses authentication to eventually install a privileged helper tool, isn't that just as unsafe?

What Zoom is doing here is clumsy, but as stephane says, the user has already provided consent at that point.

Leave a Comment