←back to thread

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

(twitter.com)
796 points _Microft | 2 comments | 31 Mar 20 11:41 UTC | HN request time: 0s | source
Show context
xenophonf ◴[31 Mar 20 13:03 UTC] No.22737073[source]▶
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.

replies(3): >>22737135 #>>22737296 #>>22737360 #
oefrha ◴[31 Mar 20 13:28 UTC] No.22737296[source]▶
> 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.

replies(1): >>22738527 #
xenophonf ◴[31 Mar 20 15:34 UTC] No.22738527[source]▶
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.
replies(1): >>22738562 #
oefrha ◴[31 Mar 20 15:37 UTC] No.22738562[source]▶
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.)
replies(1): >>22738685 #
1. xenophonf ◴[31 Mar 20 15:47 UTC] No.22738685{3}[source]▶
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.
replies(1): >>22738730 #
2. oefrha ◴[31 Mar 20 15:50 UTC] No.22738730[source]▶
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.