Live data from Hacker News

Vulnerability in the Mac Zoom client allows malicious websites to enable camera

medium.com

251–260 of 473 posts

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#252
post #203
post #189

> Our users don’t care about security. They're not wrong. Empirically, users explicitly preferred Zoom because it lacked the "ask the user" step before starting a session. Less security is a user visible advantage.

Same problem Microsoft faced when it added "UAC" in Vista. Admittedly the implementation might not have been the best from a usability perspective but I think any attempt at implementing proper privilege management in Windows would have had many users complaining and not seeing the point. I guess the lesson here is not to give your users bad habits for the sake of convenience otherwise it'll backfire if you ever want…

> Do you really think that would hurt Zoom significantly?

Zoom is a publicly-traded company now, so I am sure that adoption through convenience trumps a lot of other concerns.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#253
post #230
post #203

Earlier quoted context omitted.

Same problem Microsoft faced when it added "UAC" in Vista. Admittedly the implementation might not have been the best from a usability perspective but I think any attempt at implementing proper privilege management in Windows would have had many users complaining and not seeing the point. I guess the lesson here is not to give your users bad habits for the sake of convenience otherwise it'll backfire if you ever want…

It wasn't bad habits, up to Windows XP which introduced user separation on consumer oriented Windows (NT and 2K were meant for businesses and businesses who had networked PCs were really meant to use those) all personal computers were fully controlled by their users without any notion of privilege separation - this is a behavior that traces its lineage back to the original Altair 8800. Computers weren't networked and…

I think you make good points but to sum it up: privilege separation wasn't needed pre-internet because vulnerabilities and computer viruses weren't that big of a problem back then.

>A lot of security issues would be gone if computers weren't so connected to each other.

I mean, sure, but having computer connected together is pretty damn amazing.

I'm actually drawing the opposite conclusion compared to yours: I think UAC doesn't go far enough. You need more finely grained permissions. That seems to be the trend too: Android, SELinux, OpenBSD's pledge... It's all about giving every process only the privileges it needs and nothing more.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#255
post #147

Earlier quoted context omitted.

Not sure why he didn't just give us kill -9 $(lsof -i :19421)

For the non bash users among us?

There's nothing specifically bash about it, but here's what the components mean:

"kill" = kill running process

"-9" = kill as forcefully as possible

"$(...)" = command substitution: run the stuff inside the brackets and replace this term with the results (it will be the processes to kill in this case).

"lsof" = list open files (other things like ports and devices count as files on Unix systems)

"-i" = search for internet address

":19421" = local machine, port 19421

I think they're missing a "-t" on lsof, to make it output process IDs only ("terse mode") instead of a human-readable table:

  kill -9 $(lsof -t -i :19421)

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#256

Earlier quoted context omitted.

Oh come on. There is no easy way to send people without the app to a installer page, that is the issue. And that is something every single person wants.

Good point. Maybe MacOS/iOS should have a feature where, just like going to a custom service that can launch an already installed app, such as zoomus://123456789, they can allow software vendors to register an install URL that users who don't have the app already installed will be directed to. Let the OS handle security, where it should be, and still make the first install user experience good.

Bad behavior for unknown protocols is not a MacOS specific problem. Instead of registering things with Apple, a link to the handler should be included in the protocol link and the OS should send the user there if a handler is not installed. Something like " rel="nofollow">https://zoom.us/install">

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#257
post #2

“On Mac, if you have ever installed Zoom, there is a web server on your local machine running on port 19421.” ... “All a website would need to do is embed the above in their website and any Zoom user will be instantly connected with their video running. This is still true today!”

Does anyone know how this web server starts itself after restarting your machine? As far as I know, a `~/.zoomus` directory can't restart a web server after your machine restarts.

It doesn't start on boot, it starts on login. It appears as a Login Item named ZoomOpener in your local user account in the System Preferences -> Users & Groups.

Additionally, when you launch the main application, it will check to see whether ZoomOpener is running. If not it will boot it up. The main app will install and register ZoomOpener as a Login Item if necessary.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#258

Earlier quoted context omitted.

A custom URI wouldn't work as seamlessly as zoom's UX team would have liked. If you hadn't installed zoom, either a nasty message would tell you the protocol wasn't supported, or it would redirect you to a google search. Their answer was to send people to a URL they controlled and brought you through the install process as easily as possible, but the issue they needed to solve was determining if you needed to have an…

> The UX team You seem to imply that they have an UX team but not a security team, so nobody convinced anybody else that this wasn't a good idea. Without genuine security orientation, even if an expert realizes there is a security problem, who wants to be the boring paranoid pessimist who wastes time and attempts to ruin products, only to be staved off by the efforts of more productive employees that focus on adding…

The article indicates they have a "Security engineer" who was OOO when the author first contacted Zoom.

So yeah, sounds like one human, and it sounds like she/he probably doesn't have much say.

Post reply on HN