I have Zoom installed on my Ubuntu 16.04 and its also vulnerable.
https://jlleitschuh.org/zoom_vulnerability_poc/zoompwn_ifram...
Vulnerability in the Mac Zoom client allows malicious websites to enable camera
431–440 of 473 posts
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#432Earlier quoted context omitted.
Hmm I still don't understand why they have to use the image hack. Since they control the server on localhost they can set the CORS headers to allow all domains, then JS from a site could access localhost right?
Yes. I don't think there is any good reason to use the image hack. Further, they could have made the CORS lock only the production zoom domain for better security...
A user on Reddit suggested the image url hack was a way to bypass mixed content blocking from the zoom https site to the local http server: https://www.reddit.com/r/programming/comments/cavblo/zoom_ze...
> One potential hiccup I encountered was that Firefox blocked my XHR request due to a policy against "mixed active content". This was because my origin site was accessed through an HTTPS connection and the localhost server was only HTTP. That's one potential reason Zoom might have opted to use their garbage; since elements are passive not active content, they could avoid using HTTPS on the localhost webserver. That's not a good excuse, but clearly they weren't interested in finding a good solution -- whatever the problem that prompted the hack was.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#433One thing they were right about was this being "Standard Practice". Even spotify is doing it https://twitter.com/braintube/status/1148645026936827905.
So how does one remove these from their machine ? I can kill the process but it will just start again when I restart the machine. Also how do they do this ? I thought all startup items will be shown under Login Items in System Preferences.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#434Might also affect Discord
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#435Do people who understand networking better than I do (i.e., almost everyone) want to explain how to universally prevent this localhost garbage? Like, some kind of firewall, combined with a simple command line trigger to open up a port when I actually want to? There's gotta be an open-source firewall for this kind of thing, right? The notion that some random app can just spin up a server on localhost without my permis…
> The notion that some random app can just spin up a server on localhost without my permission is completely insane.
As far as I know any desktop app (userland code) can listen on a non-privileged port without permissions, on any desktop OS.
I’ve seen a few programs (like R) run web servers to provide documentation (although, the server only ran temporarily).
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#436Blown out of proportion. A real vulnerability I wish was handled more seriously. But at the same time, even after I “fixed” the vulnerability, my preference in Chrome to always open links for zoom, with zoom, made it nonsense. The problem is with lax browser security and CORS as a product “feature”.
It is worth underscoring that the only reason this vulnerability exists is because Safari forced appropriate prompts? Zoom hacked around it, and got away with it. That’s on browsers to fix.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#437Zoom’s UX has always come off as invasive. An application default that allows hosts to enable automatic camera join is an overstep, and the lengths they go to facilitate this while ignoring long standing, industry standard appsec guidelines to prevent XSS is relatively unsurprising yet hopefully not inconsequential to their enterprise customers.
Allowing the host to unmute participants is pretty invasive too. First time someone did that to me I was floored.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#438I always thought it was paranoid to keep tape over your webcam, but this makes a pretty good case for doing that as a last line of defense.
I also want to express my complete disbelief that Zoom basically installed a back door on all its users' machines. It's hard to imagine a competent engineer not understanding the security implications of building something like this. I have no special security expertise, so when I see an exploit that I can actually understand it scares the living daylights out of me. In this case just about anyone with a web page can trigger this Zoom vulnerability.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#439Earlier quoted context omitted.
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?
Sounds like false security thiugh- at least the camera has a light (which last I heard has been hardware level synced with the camera) so you know if someone's watching but what you have no control over is the microphone
Just audio is still an improvement over audio and video.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#440Earlier quoted context omitted.
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">
Your proposal is the closest thing to the best solution I have seen. It still has at least several issues:
* When Zoom is already installed:
- should be able to handle most instances
- needs to account for version management, eg installed version zoom could still be version that is too old to process the uri correctly. Version could be in the uri.
When Zoom is not installed:
- an information dialog needs to be somehow shown to the receiving user, asking them if they want to install 'Zoom'.
- that screen must include the 'uri' and validate certificates etc to prevent abuse (hence must necessarily be 'ugly' and not 'seamless')
- the language on that dialog has to be provided by the OS/Browser, not the software vendor, to prevent abuse. For similar reasons the Windows UAC dialog text can't be written by the vendor.
- the language employed by the OS/Browser has to of necessity be fairly neutral, neither encouraging nor discouraging installation, to prevent abuse. This is necessarily at odds with the UI principle of leading the inexperienced user through clear steps to achieve their intended goal.
- the user of average-to-lower-quartile experience, as of 2019, for a product with a client base of 40 million+, is likely not in a position to meaningfully distinguish a legitimate Zoom install uri from a malicious / imposter one. Hence any popular software using this install-from-uri-handler becomes an appealing target for malicious actors to mimic, which they will.
- some proportion of users will likely install from malicious links, and whichever product (let's say Zoom for example) is the most likely software for malicious actors to masquerade as will become the name associated with the attack in the mind of the wounded public