Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

341–350 of 473 posts

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

#341

Post by ChikkaChiChi »

rahoulb wrote: post #176

I asked Zoom support about this and they sent me to this page: https://blog.zoom.us/wordpress/2019/07/08/response-to-video-... The key thing here is they think this is a fair trade-off because Safari asks if you want to open Zoom. > This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enabl…

Not on my machine. I uninstalled with AppCleaner, visited a Zoom link in Safari, and the software reinstalled and started without my interaction.

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

#342

Post by briandear »

> Second, when Zoom is installed on a Mac device by the user, a limited-functionality web server that can only respond to requests from the local machine is also installed on the device. This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enables users to avoid this extra click before joining every meeting. We feel that this is a legitimate solution to a poor user experience problem, enabling our users to have faster, one-click-to-join meetings. We are not alone among video conferencing providers in implementing this solution.

A workaround to legitimate Safari security improvements.

I hope the Wall Street Journal and CNBC skewer this company and shred the stock price.

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

#343

Post by hamburglar »

robinhouston wrote: post #183

Zoom’s response to this[1] is a wonderful example of how not to respond to security issues. It includes the classic tropes: * Our users don’t care about security. > Our video-first platform is a key benefit to our users around the world, and our customers have told us that they choose Zoom for our frictionless video communications experience. * We have no way of knowing if this has been exploited in the wild, so it’s…

Also, they seem almost entirely focused on "unwittingly joining a meeting" as the real problem here, ignoring the fact that they have made the extremely poor choice of exposing a dodgy control API on your mac to the entire internet. What are the odds there are no bugs in this shitty little HTTP server they snuck onto everyone's machine? The fact that they came within five days of losing control of one of the domains that has the power to install arbitrary code on every mac running this thing is absolutely insane, and they should be asking themselves 1) how that happened, and 2) how utterly screwed they would have been if they lost control of that domain.

In a more amusing alternate universe, someone discovered the zoomgov.com vulnerability, waited until it expired, snapped it up, then published an "update" that uninstalls zoom entirely. In a nastier one, they used this idiotic design flaw to pwn every zoom client machine out there.

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

#344

Post by sombremesa »

fokinsean wrote: post #319
chrisfosterelli wrote: post #157

Earlier quoted context omitted.

That's correct, and part of my point. If they used CORS headers correctly it could both be secure and not require a crazy image hack. The image hack seems like a lot of work to go through to make an app LESS secure.

I'm a bit confused, so CORS doesn't apply when trying to load an image? If they set CORS to allow interaction from anywhere, why use an image and not load data with js?

CORS is set up to protect data from being given to a third party, e.g. JS requests obtaining and being able to observe data they shouldn't have access to. Since images are being loaded by the browser (second party), there is no such protection, since a third party should not be able to read them anyway (barring some other vulnerability). It's assumed the first party is correctly doing what it's supposed to, an example could be fetching an image from a cdn.

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

#346

Post by thinkmassive »

robbiemitchell wrote: post #323
wl wrote: post #298

Earlier quoted context omitted.

Without the local webserver, they fall back to Safari's URL handler, which asks whether or not you wan't to start the application in question. They went through a lot of trouble to implement this ridiculous solution to avoid the kind of thing you describe.

I mean _with_ their local webserver, can they implement their own, simple confirmation of some kind?

“This [local webserver] is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting.”

https://blog.zoom.us/wordpress/2019/07/08/response-to-video-...

According to Zoom the intended purpose of the local webserver is specifically to avoid the confirmation step.

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

#347

Post by fokinsean »

ukd1 wrote: post #335
fokinsean wrote: post #321

Earlier quoted context omitted.

Could you further explain the CORS bypass? Why do they have to do the image hack if CORS if they open up CORS on the local server? At that point couldn't they retrieve data via JS instead?

CORS isn't supported to localhost, aka you can't do that; hence the image-size hack

But the image is being served from localhost no? Do image requests not abide by CORS?

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

#348

Post by rahoulb »

robbiemitchell wrote: post #323
wl wrote: post #298

Earlier quoted context omitted.

Without the local webserver, they fall back to Safari's URL handler, which asks whether or not you wan't to start the application in question. They went through a lot of trouble to implement this ridiculous solution to avoid the kind of thing you describe.

I mean _with_ their local webserver, can they implement their own, simple confirmation of some kind?

Well - Safari asks you for confirmation. They built the local, exploitable web-server to avoid the confirmation message. Why would they go to that trouble, only to reimplement what they were trying to avoid?

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

#350

Post by anaphor »

Crinus wrote: post #328
simias wrote: post #253

Earlier quoted context omitted.

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 U…

Finely grained permissions mean bad UX and as Android has shown you gain nothing practical from that since the people will learn to ignore them pretty much like they learn to ignore the UAC warning while on the other hand you lose the flexibility, functionality and openness of the entire system (all significant pillars for ensuring user control). Note that i'm not saying to disconnect computers entirely, i'm saying t…

This is what things like https://sandstorm.io and Google's Fuchsia OS are trying to solve. Of course it requires a huge shift in how you design applications, but it does not impose any burden on the user's side really. They just allow $APP access to some data or resource, and then it has access to only what it needs going forward, with no need to allow it every time (unless you revoke it). This can be done when the app gets installed, so there's no UX problem really.
Post reply on HN