Hacker News Reader

Comment by fiddlerwoaroof | Hacker News Reader

I still don’t understand the issue with this: it’s not using this feature as intended, but they’re not exploiting any vulnerabilities or attempting to exploit a privilege escalation bug in macOS. Apple’s installers allow these scripts to do anything (and I believe there’s a prompt along the lines of “this installer will run a script to determine if the package can be installed”).

View on HN

> “this installer will run a script _to determine if the package can be installed_”

Why would the user expect that script to install the application, or even modify their system in any way?

The fact that Apple allows an application to be installed in this step is an issue with Apple's design.

It’s a script, though; should they sandbox the preinstall phase? That would break most packages.

Instead of silently breaking they could have a popup like "Do you allow the preinstall script to write into /this/folder?" on a write operation outside of the sandbox.

99% of users will have no fucking idea what that means. They will either click 'Allow' (which makes this feature useless for 99% of people) or contact tech support (adds friction to installation, which is bad especially for conferencing software) or just give up and not use the product (which is bad for the company).

To be fair, it would at least ruin Zoom's incentive to do any of this, since they wanted a streamlined process that prompts the user less.

Why they didn't just use a dmg that has you drag the application into /Applications/ is something I still don't understand though. Surely that is the simplest most user friendly way to have non-technical users install applications without using the appstore.

Maybe so, but that doesn't excuse those exploiting that flaw.

To be fair, Apple has rectified this flaw by writing the Mac App Store, where applications can't pull these shenanigans and are properly sandboxed from one another.

Why is the store relevant to sandboxing?

They only allow sandboxed apps to be placed on the store.

“This installer will run a script to determine if the package can be installed.”

Not “This installer will run a script that installs this package without asking further questions, then terminate abruptly without going through the rest of the install process and giving you a chance to decide exactly where it should go”.

I always read the subtext as "This installer will run a script whose stated goal is to determine if the package can be installed, but y'know, it's a script, and its existence is warranted for doing supposedly helpful yet nonstandard checks that the pkg API-or-something doesn't provide, thus can't be sandboxed, and therefore can do anything else it wants to. Would you like to assume trust and proceed anyway, or would you rather cancel and possibly audit the thing beforehand?".

But that's my paranoid tech background speaking. I can totally understand technical naïveté though.

Zoom and WebEx are certainly taking that subtext but I am pretty sure that is not the intended subtext of that statement. :)

MacOS stupidly runs that script as a user with write permissions.

They may not be exploiting vulnerabilities but they are breaking the contact with the expectations users have of how installers work.

>with the expectations users have of how installers work

Tbh I think that most people here on hn are experiencing cognitive bias because of additional knowledge - reality is that most of regular users do not give a damn about what installer does, they just want working app.

But why are they even using Installer.app? First, why use an installer at all; second, if they really want an installer, why not make a custom installer app and avoid the "run a script" prompt? Installer.app doesn't have special privileges. Is the script approach just easier?

The built-in installer gives developers a lot of freebies like permission escalation and gets around "hey, you're trying to run a program from the internet" prompt. That is at least until developers start bending over backwards with crazy shell scripts like the one found in the zoom installer.

The interesting thing is that if you hit Command-I and Command-L you can see exactly what the package is doing, and the most recent one just seems to be moving an app to /Applications. For this sort of thing: download a zip, open the zip from your browser's download panel and then have the app move itself to /Applications when you open the extracted app is a much nicer flow that is semi-widespread.

Enterprise deployment?

Being only sub-consciously aware of the difference is still an impact. The repetition of the install process should lead toward more familiarity with how the process works. The zoom and cisco installers are breaking that repetition and replacing it with something unexpected.

The thing is that Zoom isn't installing the package either! If you look at the list of installed pkgs after installing Zoom there is no Zoom package.

They are using a .pkg only for the side effect of running a pre installation script that simply copies Zoom.app in the /Application directory. That is to a software develper garbage, why doing so, when all other macOS application require the user a single drag and drop?

Sure, that is probably not malware, but is a very poor practice, gives the user a bad experience, for no reason. These are the things that let's you wonder if the installation is managed in such a poor way how is the rest of the infrastructure.

Why are they doing that? How is it easier than just having the app self install?

It isn’t a _security_ issue, because the script doesn’t circumvent any security restrictions, but it is a _trust_ issue, because the script abuses pre-install functionality to install the program without explicit user agreement: A Mac user expects a confirmation prompt, but never receives one.

Can you point to data which shows that Mac users expect confirmation prompts? Because my thoughts are that no, Mac users don't have any expectations from installers other than to get out of the way as quickly as possible (which the script approach achieves).

This is an issue with the installers. The fact that installers on macOS still work like in the 90s baffles me -- I thought they had done something smart with sandboxes, APIs for system privileges, and a "secure path" where user consent uses system-controlled GUI.

This issue mainly tells me that macOS installers are largely like a Windows .exe and Linux curl | sh (well, that's not true since it still needs to be signed…).

Installers aren’t really the preferred way to distribute software on a Mac, unless you need special access to the system for some reason. Most Mac software is distributed as an application bundle that’s dragged wherever you want on the file system and then run by double-clicking.

I would go as far to say that a good chunk of more technically inclined Mac users have a tendency to view any user facing software that requires an installer with suspicion.

Reply on news.ycombinator.com