Most active commenters
  • Wowfunhappy(9)
  • danieldk(4)
  • tantalor(3)
  • saagarjha(3)

←back to thread

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

(twitter.com)
796 points _Microft | 38 comments | 31 Mar 20 11:41 UTC | HN request time: 0.002s | source | bottom
Show context
lultimouomo ◴[31 Mar 20 12:08 UTC] No.22736730[source]▶
I think this also shows how macOS has been training users to enter their password in random dialogs that have absolutely nothing that identifies them as being legit OS dialogs. The dialog that Zoom uses could very well be sending the credentials to a remote server, and the user would be none the wiser.
replies(2): >>22736941 #>>22742904 #
1. Wowfunhappy ◴[31 Mar 20 12:44 UTC] No.22736941[source]▶
Note that in this case, it's still a legit OS dialog. Preflight scripts are very much built into the macOS pkg format, they're just not intended to be used like this.
replies(4): >>22737018 #>>22737061 #>>22738118 #>>22741908 #
2. tantalor ◴[31 Mar 20 12:56 UTC] No.22737018[source]▶
It doesn't look legit, it looks like the installer script is faking a system dialog in this screenshot:

https://twitter.com/c1truz_/status/1244737675191619584/photo...

This message is a lie; it not coming from system but from the installer script.

Just because the OS is used to show the dialog doesn't mean it should be trusted. As other commenter noted this could be used to steal passwords; that is effectively what it does.

replies(2): >>22737159 #>>22737550 #
3. danieldk ◴[31 Mar 20 13:02 UTC] No.22737061[source]▶
I never understood why Apple still supports the pkg format. It seems a half-baked leftover from the 2000s and even then I was already surprised that there is no way to uninstall things through the macOS GUI. I am not sure if this has changed (I try to avoid pkg files and use Homebrew cask to uninstall such packages), but IIRC you had to list the files with pkgutil on the command-line, remove stuff by hand and then --forget the package.

They should just kill the format. Everything should just be drag to install, drag to trash to remove.

replies(5): >>22737190 #>>22737837 #>>22737980 #>>22747295 #>>22747843 #
4. rainforest ◴[31 Mar 20 13:15 UTC] No.22737159[source]▶
To their credit, they seem to be using AuthorizationExecuteWithPrivileges which doesn't get the user's password, but executes a command as root, which is marginally better than stealing the password like Dropbox did.
replies(1): >>22737179 #
5. tantalor ◴[31 Mar 20 13:16 UTC] No.22737179{3}[source]▶
How hard do you think it is to steal a password once you have root?
replies(2): >>22737310 #>>22740559 #
6. javagram ◴[31 Mar 20 13:17 UTC] No.22737190[source]▶
In my experience I’ve seen even technical users (Who were used to windows) struggle with the idea of dragging an .app from an open disk image to the Applications folder. They would end up running the app from the disk image and then getting confused when it disappears after restart.
replies(2): >>22737624 #>>22737658 #
7. swiley ◴[31 Mar 20 13:30 UTC] No.22737310{4}[source]▶
It would take an extra step, you have access to the hash and maybe shared memory/SOs but you’d need a second trick to actually steal it.
8. Wowfunhappy ◴[31 Mar 20 13:57 UTC] No.22737550[source]▶
The script asks for root which subsequently pops up an OS password prompt. Zoom never sees your password.

How is this different from the way e.g. Virtualbox gets root?

replies(2): >>22738134 #>>22738303 #
9. Wowfunhappy ◴[31 Mar 20 14:05 UTC] No.22737624{3}[source]▶
This system worked so much better when the Applications folder was placed in the Dock by default, and everyone used that folder launch applications (which weren't common enough to keep in the Dock directly).

It was actually a really beautiful synergy—you install applications by copying them to a folder, and launch them from that folder. Same way you'd acquire and open files. Lovely.

Then Apple ruined it in Lion with Launchpad. Their app install flow for anything outside of the app store doesn't make any sense.

replies(1): >>22744136 #
10. AnIdiotOnTheNet ◴[31 Mar 20 14:09 UTC] No.22737658{3}[source]▶
One wonders why Apple didn't just treat DMGs like Application Folders in the first place. If they had an icon and you could run them directly then there wouldn't be any confusion. AppImage works like that and I think it was a wise decision.
replies(1): >>22737872 #
11. drampelt ◴[31 Mar 20 14:30 UTC] No.22737837[source]▶
> Everything should just be drag to install, drag to trash to remove.

I wish it were that easy, most apps leave files in other places on your computer like ~/Library that will never get cleaned up if you just move the app to trash.

replies(1): >>22738101 #
12. Wowfunhappy ◴[31 Mar 20 14:34 UTC] No.22737872{4}[source]▶
Developers can distribute .app's inside of .zip files, and many do, but this can result in users just running the .app inside of their downloads folder. And then this causes problems if they ever decide to clean out their Downloads folder.

The DMGs are a clever way to (A) make sure the app gets to the proper location while simultaneously (B) teaching the user about what's actually happening on their computer. As I said in a sibling comment, this all made much more sense when users also launched apps from the Applications folder directly.

replies(2): >>22738217 #>>22766252 #
13. samcat116 ◴[31 Mar 20 14:44 UTC] No.22737980[source]▶
One thing to note here: people who administer macOS for organizations basically convert everything to .pkgs (or DMGs). Its the only easy way to silently install application, and perform post install actions like performing licensing or activation steps.
14. Wowfunhappy ◴[31 Mar 20 14:55 UTC] No.22738101{3}[source]▶
As much as this bothers me because of who I am, I don't think it's a real problem. Those files shouldn't take up significant space unless the developer is doing something stupid.

It might be nice if macOS had some sort of automatic cleanup routine when an app is trashed, but that would either require showing the user an extra dialog (a la AppCleaner's) or introducing an opaque system which could potentially lead to data loss.

replies(1): >>22738249 #
15. lonelappde ◴[31 Mar 20 14:57 UTC] No.22738118[source]▶
Incorrect. Look at the second tweet in the thread. It's a phishing popup that misidentifies itself in order to steal priveleges intended for System, not Zoom.

https://mobile.twitter.com/c1truz_/status/124473767519161958...

replies(1): >>22738224 #
16. lonelappde ◴[31 Mar 20 14:59 UTC] No.22738134{3}[source]▶
Because it lies about its identity, calling itself "System" not Zoom.

This is also a MacOS vuln that lets apps lie about their identity in sudo prompts, much like a browser showing an https site with no certificate checking.

replies(1): >>22738200 #
17. Wowfunhappy ◴[31 Mar 20 15:05 UTC] No.22738200{4}[source]▶
macOS allows apps to write arbitrary lines of text above password prompts, which is what Zoom is doing. I don't see how that's different from a shell script echo'ing something before a sudo prompt.

How would you design this system?

replies(1): >>22740596 #
18. danieldk ◴[31 Mar 20 15:07 UTC] No.22738217{5}[source]▶
Developers can distribute .app's inside of .zip files, and many do, but this can result in users just running the .app inside of their downloads folder. And then this causes problems if they ever decide to clean out their Downloads folder.

Some applications offer to move themselves to the /Applications folder when started the first time outside /Applications or ~/Applications. Though in general, it would be better if Apple made it more attractive to publish in the App Store, since it brings other advantages (e.g. mandatory sandboxing).

replies(2): >>22738918 #>>22745753 #
19. Wowfunhappy ◴[31 Mar 20 15:08 UTC] No.22738224[source]▶
That's still an OS prompt, they just put their own message at the top, as you're allowed to do.
replies(1): >>22741551 #
20. danieldk ◴[31 Mar 20 15:10 UTC] No.22738249{4}[source]▶
Indeed, data outside the application folder usually consists of a preferences plist and saved application state. Of course, there could be caches as well, which could take up a fair amount of disk space.

But I think the primary argumentation in favor of what macOS does now on drag-to-trash is that the users preferences are preserved, for when they install an application again.

21. auiya ◴[31 Mar 20 15:15 UTC] No.22738303{3}[source]▶
It's not making the proper privilege escalation call, it's faking the box entirely. There's even a typo in the dialog box.
replies(2): >>22738340 #>>22742584 #
22. Wowfunhappy ◴[31 Mar 20 15:19 UTC] No.22738340{4}[source]▶
...are you sure? I'm pretty sure that code just pops up the system box to get privileges, with a custom message at the top.

I'm running Mavericks—the last version of macOS before they made the UI flat—and the prompt didn't look out of place. If Zoom is indeed faking the box, they actually went through the trouble to make a separate version for Mavericks with Mavericks-style visuals.

23. Wowfunhappy ◴[31 Mar 20 16:06 UTC] No.22738918{6}[source]▶
Yeah, and that's a fine solution given the situation Apple has left us in. But it's also kind of a hack, which shouldn't have become necessary.

Also, personally, I sometimes purposefully put apps in places other than /Applications—for example, I like to keep games in their own Games folder. And then the dialogs are kind of annoying.

24. jedieaston ◴[31 Mar 20 18:14 UTC] No.22740559{4}[source]▶
It should be impossible with SIP enabled, as in OS X 10.14 Apple protected the files in /var/db/dslocal where the user shadow files are stored so that root could not read them (unless triggered by an Apple signed executable, like Software Update). If you are running with SIP disabled you've taken the risk of it happening, and if you are on a corporate laptop (or 99% of personal machines) it is engaged.

https://apple.stackexchange.com/questions/344117/mac-10-13-1...

replies(1): >>22741172 #
25. jedieaston ◴[31 Mar 20 18:16 UTC] No.22740596{5}[source]▶
Don't allow the application to do any of it, and when the app asks for access, have the system instead say "{processName}.app is requesting {permissionFlavorText}. Enter a name and password to continue."
26. tantalor ◴[31 Mar 20 19:02 UTC] No.22741172{5}[source]▶
Think a little harder. With root, you can install a keylogger.
replies(1): >>22742525 #
27. joshuaissac ◴[31 Mar 20 19:35 UTC] No.22741551{3}[source]▶
Yes, they are allowed to put a fake message (identifying the requester as System instead of Zoom), but that does not make it OK.
28. thaumasiotes ◴[31 Mar 20 20:07 UTC] No.22741908[source]▶
> Note that in this case, it's still a legit OS dialog.

No it isn't. The dialog prompt is "System need your privilege to change." That's not passing QA anywhere -- it's just a custom message someone put into Zoom without bothering to proofread.

29. saagarjha ◴[31 Mar 20 21:00 UTC] No.22742525{6}[source]▶
You'd still need to bypass TCC.
30. saagarjha ◴[31 Mar 20 21:06 UTC] No.22742584{4}[source]▶
No, they're using the (deprecated) Authorization Services API from the (renamed) BLAuthentication.
31. Smoosh ◴[31 Mar 20 23:53 UTC] No.22744136{4}[source]▶
In even earlier days, applications didn't need to be installed at all. You just ran them from wherever they were. Of course, it made sense to store them somewhere together, and you could cause yourself problems if you put applications onto disks you then ejected. But the current system is clearly influenced by the UNIX underpinnings, and I'm not sure that the average user fully "gets it".

though preferences files were a bit of a mess.

I vaguely remember if early Macintosh System versions you would be prompted to insert the disk (with the correct disk name in the message) if you tried to open a file belonging to an application which was on an ejected disk.

replies(1): >>22745817 #
32. kelnos ◴[01 Apr 20 04:40 UTC] No.22745753{6}[source]▶
Hell, why doesn't Finder do this? If you try to run a .app from a .dmg, it should pop up a dialog asking you if you want Finder to move it to /Applications for you and run it from there.
replies(1): >>22746098 #
33. int_19h ◴[01 Apr 20 04:52 UTC] No.22745817{5}[source]▶
You can still run them from wherever they are. The problem is that users do that once, exit, and then later forget where the app was.
replies(1): >>22746119 #
34. danieldk ◴[01 Apr 20 05:52 UTC] No.22746098{7}[source]▶
I agree, that would be awesome!
35. saagarjha ◴[01 Apr 20 05:57 UTC] No.22746119{6}[source]▶
There are issues when running from the downloads folder (translocation).
36. fouc ◴[01 Apr 20 10:27 UTC] No.22747295[source]▶
pkg is there explicitly to let companies install sketchy shit. Any application that relies on pkg to be installed is fundamentally risky.
37. latexr ◴[01 Apr 20 12:11 UTC] No.22747843[source]▶
If the pkg format was no longer supported, developers might use GUI installers instead, and those are harder to verify and install/uninstall programmatically.
38. ksec ◴[03 Apr 20 04:08 UTC] No.22766252{5}[source]▶
I thought some of these interaction was from a design where Apple wanted the Mac to be more appliance. I think the goal / target market has changed. The super easy to use Computer to use is now the iPad.

Mac is now Prosumers and Professionals. And its UX should be treated as such.