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

331–340 of 473 posts

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

#331

Post by yoz-y »

Crinus wrote: post #325
yoz-y wrote: post #264

Earlier quoted context omitted.

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

I agree that less connectivity is better for security, which is why I think rushing to IoT-everything is premature.

However unless a computer cannot be physically connected to the internet, it must implement all of the protections it can. Just not having wifi enabled or cable disconnected is a false sense of security.

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

#333

Post by derekjhunt »

samstave wrote: post #304
_pmf_ wrote: 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.

Also, most users of zoom are job applicants - so theyre more likely to care less abt security because they really need to be in that interview session.

This is not even remotely true. We use at everyday at my workplace (Education) - thousands and thousands of employees as well as students . All of our contemporary peer institutions do the same.

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

#335

Post by ukd1 »

fokinsean wrote: post #321
ubermonkey wrote: post #312

Earlier quoted context omitted.

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?

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

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

#336

Post by guitarbill »

mkl wrote: post #255
sooheon wrote: post #167

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…

although command substitution is in the POSIX sh spec and so not a bashism, $(...) doesn't work in e.g. fish

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

#337

Post by ljm »

cobbzilla wrote: post #96

I'm trying to think of the real-world implications and how this would play out. Normally this would be pretty obvious, wouldn't it? Users would see Zoom open into some weird meeting, and close it. Presuming the exploit cannot avoid bringing the Zoom app to the foreground when it joins the meeting and activates the camera/mic. If it can do that and stay in the background, all bets are off. In spite of its obviousness,…

Scenario 1 extended: Add this into an ad or a popover for a porn site and potentially capture some very compromising footage.

Scenario 3: Add it as a tracking pixel in an email.

I guess there are all kinds of scenarios since it's an unsecured API that responds with an image. You can trivially embed it in anything that renders HTML.

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

#338

Post by cpncrunch »

The title is click-baity. What it allows is a website to automatically join you into a meeting with the camera enabled and without you asking. So it's annoying, but it doesn't let a website secretly grab your video without you knowing.

The reason webrtc has permissions per site is because webrtc can indeed grab your video without you realising, so it's important to give each site permission to use your camera. This isn't the case with zoom...it pops up a massive window when you enter the meeting.

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

#339

Post by TeMPOraL »

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…

> 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)

Won't work. Malicious actors (both malware developers and companies with user-hostile business models) will start working around it, by for instance giving you two applications, one connected to the Internet and one not. The first application will be the C&C server, the second one will be the executor, and they'll talk with each other over e.g. files in first application's folder.

Trying to block that would pretty much hose all utility in having a general-purpose computer. You'll be back to the crappy UX of a smartphone.

I honestly don't know how to solve this conundrum. You can't solve it technologically, as you quickly hit the Halting Problem. You can't solve it socially, because for any power user benefiting from the modicum of interoperability you leave in, you get 10 regular people who can be trivially social-engineered into selfpwning their device. It seems that in the end, you'll either have to lock down computers to near uselessness, or live with the risk of bad actors exploiting them.

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

#340

Post by ilikepi »

kofejnik wrote: post #322
xenadu02 wrote: post #181

Earlier quoted context omitted.

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)

It's not to hard to extract the app bundle from the .pkg file. This is how I've always installed it. Do this from an empty directory, though, since it will just spray files everywhere...

* Use `xar` to extract the contents of the .pkg file:

    $ xar -xf Zoom.pkg
* Use `cpio` to extract the payload, which is in a file oddly named "Scripts":

    $ mkdir payload && cd payload
    $ cpio -i -d
* The app bundle is compressed within a 7z archive, but the .pkg file contains a precompiled decompressor. Either use that or install your own (e.g. via Homebrew) to extract the app bundle:

    $ 7zr x zm.7z
Now you will have a directory called "zoom.us.app", which is the app bundle. Move this to wherever you want it to live, and now you've "installed" the app without running the scripts from the .pkg.

Importantly, note that the app will still exhibit the behavior discussed in the article. When you run it the first time, it will install ZoomOpener, which is the helper app that includes the web server. It will not install any browser extensions, however, which is the behavior I was originally trying to avoid by going through this procedure.

Post reply on HN