Live data from Hacker News

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

medium.com

321–330 of 473 posts

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

#321

Earlier quoted context omitted.

It's ridiculous to install a constantly running web service that uses tricks to circumvent CORS protection and to get around Safari's protections, which were both rightly created to improve user's security. It's not a "so-called vulnerability". As the article describes, this could be used in concert with another vulnerability to achieve RCE. Combining vulnerabilities is often how RCE is attained. These actions undo t…

Yeah, I was focussing on the webcam thing. That piece, taking individually, isn't a big deal. But the web server / CORS bypass is completely fucked up, nefarious, and unforgivable. Accordingly, I edited my post.

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?

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

#322
post #172

Why isn't the Windows client vulnerable? What have they/Microsoft done differently?

Safari asks you if you want to open an app that owns a URL scheme to prevent webpages from automatically triggering behavior you might not want. Zoom decided they know better than the Safari team and decided to install this local webserver specifically to bypass the operating system's security policies, supposedly because "it is their key differentiator" or whatever. Basically their product managers decided they want…

you forgot one more thing: they don't distribute their crap as a regular self-contained .app, they give you a .pkg which asks for elevated privileges during installation (this is why I don't have it installed)

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

#323
post #298

Can’t Zoom add their own simple prompt to the local server which gets confirmation from the user that they want to join the meeting? Just one more click and not “nasty”. It could even be 4 different Join buttons: - Video & Audio - Video Only - Audio Only - No Video or Audio

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?

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

#324

On my Mac, I have uBlockOrigin installed in my browser and I have it configured to always block 3rdparty and 3rdparty frames and it prevents both the POCs completely. I have one browser that I use for work email and video conference, where system grants access to camera/microphone to the browser and browser allows Google Meet to access camera. I have another browser where system does not grant access to any of the de…

and I am in the crowd of mac users who tape over their camera. when it comes to video conferences at most I have ever seen the desktop shared. what type of work do you do that uses the video for portions other than the presentation?

Video meetings are so much more effective than audio meetings. I went from a company that always uses video to a company that rarely uses video and the difference is huge.

Often the most important parts of meetings are nonverbal.

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

#325
post #264
post #230

Earlier quoted context omitted.

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’ve had viruses and anti viruses years before I had internet. Getting a virus was trivial in the 90’s when windows had no security and any program could do anything.

Any program can do anything in modern Windows too, only special places like C:\Windows\System[32] are protected. I'm not against such protections since they can be easily overridden if needed and in day-to-day use they do not harm anyone nor affect negatively the usability of the system.

I'm not saying that we should go back to 90s entirely, we have a lot of good improvements over the years. I'm just hoping we'll tone down the "connect all the things" a bit since that is the main source of a lot of security issues.

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

#328
post #253
post #230

Earlier quoted context omitted.

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 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 to rely less on connected computers. Simple stuff like use LibreOffice or MS Office instead of Google Docs, use a desktop calendar and other tools instead of relying on "web apps", instead of using a "cloud-based solution" for syncing data with your mobile phone, just connect it directly to your computer (via wifi, bluetooth, whatever - this is a UX issue mainly - but it doesn't have to roundtrip with someone else's server). Stuff that makes you and your computer less reliant on the network.

Not everything can work like that of course, but then instead of trying to isolate applications from each other using fine-grained separation, we can simply treat the network itself as hostile and try to defend from it (e.g. applications that can access the network cannot access outside of a designated folder - the OpenBSD pledge approach but forced on all applications that access the network). I think it is a much easier, flexible, user controllable and understandable approach than UAC on steroids or any other approach that relies on application segregation.

It does require a massive shift in developers' mindsets and profit incentives for companies though, which is why i do not see such a thing happening.

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

#329

Earlier quoted context omitted.

Once you deleted the localhost server they have running, they actually fallback to using the protocol.

Can you reliably delete the server?

Yes, you just need to

  rm -rf ~/.zoomus
  touch ~/.zoomus
The opener is the only thing in that directory.

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

#330
post #255

Earlier quoted context omitted.

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

That "command substitution" bit will fail on tcsh, say, last I checked.
Post reply on HN