91–100 of 473 posts
Earlier quoted context omitted.
Have your checked for similar vulnerabilities in competing products such as GoToMeeting and WebEx? They have the same basic features.
bluejeans video installs a nasty daemon that runs at boot too. I'll never attend a bluejeans meeting again
> This vulnerability leverages the amazingly simple Zoom feature where you can just send anyone a meeting link (for example https://zoom.us/j/492468757 ) and when they open that link in their browser their Zoom client is magically opened on their local machine. I was curious about how this amazing bit of functionality was implemented and how it had been implemented securely. Come to find out, it really hadn’t been im…
below down the post, zoom team said that this feat exists because Safari doesn’t have custom url scheme.
One of the first times I'd ever used Zoom was in a call with a startup trying to pitch my company on something. The remote participant said something later in the call that was uncannily prescient and related to notes I had in a separate application window. I wrote it off as coincidence, but the phrasing used (and the fact that it was an answer to a question I hadn't asked) seemed nearly verbatim to my written notes.
Why isn't zoom running fully in the web browser at this point? Meet does this, and as far as I can tell the quality is indistinguishable from Zoom. Can someone with a better understanding of the underlying protocols shed light on why Zoom continues to ship a separate desktop app?
> This vulnerability leverages the amazingly simple Zoom feature where you can just send anyone a meeting link (for example https://zoom.us/j/492468757 ) and when they open that link in their browser their Zoom client is magically opened on their local machine. I was curious about how this amazing bit of functionality was implemented and how it had been implemented securely. Come to find out, it really hadn’t been im…
The basic problem is that you enter a meeting by loading a URL, and loading URLs is something any website can do. There probably needs to be a confirmation step before joining a meeting.
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, it's still pretty darn scary --
Scenario 1: malicious website/app opens link while you're sitting there.
You're sitting in front of your computer, you see Zoom open, you're like "WTF?!", close that shit, uninstall Zoom; hopefully discover how to permanently remove it (it otherwise leaves a localhost http server running that can reinstall itself).
But crap the hijackers have, even with a few seconds of video: your face, your surroundings, the audio of your surroundings, all of which can increasingly be fingerprinted. That alone is very scary. Just to be in an unintentional meeting for a moment is very disturbing. A violation of sorts.
Scenario 2: malicious website/app delays opening the link until some threshold of mouse/KB inactivity is reached.
Activate the Zoom link and hope the person is AFK. Spy on their home/office/whatever. Also a violation.
Are there other scenarios I am missing?
Personal note 1: I'm happy I switched to a Linux laptop after finding last year's MBPs disappointing (and the TB revolting; I have a physical escape key!).
Personal note 2: I do actually like Zoom a lot, it's an awesome video conferencing app. But this should be fixed for Mac users.
For example, the default audio setting when you sign in to the web video client is to connect using PHONE AUDIO. In case you figure out how to click the tab to use computer audio...it breaks down a couple of time in asking for browser permissions (camera, mic). It is unusually bad for something that is supposed to be that good.
there are all these articles about the comparisons - https://webrtchacks.com/zoom-avoids-using-webrtc/
https://bloggeek.me/webrtc-vs-zoom-video-quality/
hangouts still rules when it comes to web based video conferencing. And for countries with massive linux based usage (like India), Zoom is not a very viable option.
I'm nearly positive that CORS from localhost works OK. I set this up all the time for local development. For example, I run a client CRA app on localhost:3000 and an API on localhost:3001. The API sets the CORS headers and the CRA app can make requests to it.
If this is correct then I believe all Zoom needed to do is have their localhost application set CORS headers for their production domain. This would have allowed AJAX communication and only allowed it for Javascript running on their domain. Instead they did this totally hacky method that lets the whole world interact with the localhost server...
Maybe I missed something but if they could have done this the right way and didn't that is much worse IMO...
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…
Ah, yeah, the flow for when the app isn’t installed makes particular sense (at least as a motivation for why someone would implement something so awful). Thanks!
> Zoom believes in giving our customers the power to choose how they want to Zoom.
Zoom believes if their app isn't convenient to use, their customers have the power to leave their ass, as they are in an incredibly competitive market.
> This includes whether they want a seamless experience in joining a meeting with microphone and video automatically enabled, or if they want to manually enable these input devices after joining a meeting.
This includes making sure that they aren't asked to provide confirmation to access their camera/microphone, which impedes the convenience of the app to all participants. Less clicks equals less thinking.
> Such configuration options are available in the Zoom Meeting client audio and video settings.
Stop complaining about this as we have given ourselves a legally compelling user defined control hidden in a single tab deep within our preferences.
> However, we also recognize the desire by some customers to have a confirmation dialog before joining a meeting.
We can tell you aren't going to drop this.
> Based on your recommendations and feature requests from other customers, the Zoomteam [sic] is evaluating options for such a feature, as well as additional account level controls over user input device settings. We will be sure to keep you informed of our plans in this regard.
We don't care. We have lots of users, and lots of success having this option turned on by default. The support costs alone telling non-technical people how to turn on their cameras don't make it worth it.