...&#x2F;.zoomus&#x2F;ZoomOpener.app&#x2F;Contents&#x2F;MacOS&#x2F;ZoomOpener

I’m surprised more enterprise IT orgs haven’t flagged this behavior, or simply made it impossible via local machine policies that would prevent running a web server.

I&#x27;m sure Zoom intentionally failed to tell you how to remove the web server. After all, if it&#x27;s still running, then it&#x27;s just that much easier to reinstall Zoom on your machine.

This server is still running on my machine despite having &quot;removed&quot; Zoom a few months ago (macOS).Guess I was a bit naive in thinking just trashing the .app and immediate artifacts in Library would do the trick.EDIT: I missed the .zoomus directory in my home folder that had the culprit. Funny enough Zoom&#x27;s instructions on how to uninstall the app on macOS just points to documentation from Apple and wikiHow (???) with standard methods that don&#x27;t fully remove Zoom.

I think it&#x27;s because it runs on a port higher than 1024, so it doesn&#x27;t need root privileges to start a web server on that port.

It doesn&#x27;t start on boot, it starts on login. It appears as a Login Item named ZoomOpener in your local user account in the System Preferences -&gt; Users &amp; Groups.Additionally, when you launch the main application, it will check to see whether ZoomOpener is running. If not it will boot it up. The main app will install and register ZoomOpener as a Login Item if necessary.

Does anyone know how this web server starts itself after restarting your machine? As far as I know, a `~&#x2F;.zoomus` directory can&#x27;t restart a web server after your machine restarts.

“On Mac, if you have ever installed Zoom, there is a web server on your local machine running on port 19421.”...“All a website would need to do is embed the above in their website and any Zoom user will be instantly connected with their video running. This is still true today!”

&gt; users should be informed right away so that they can take steps necessary to secure themselvesFor the record, this could be accomplished by a trustworthy source announcing &quot;there is a critical vulnerability in Zoom&#x27;s macOS software and you should uninstall it immediately pending vendor response&quot;. Some researchers do this already -- Tavis Ormandy has, for example.It&#x27;s not a binary choice between no disclosure and releasing an unpatched PoC.By the way, I&#x27;m not trying to argue that this researcher behaved unethically, just sharing another option. My usual take is that the researcher gets a lot of leeway for having to make a difficult decision and presumably trying their best to balance consequences, similarly to how a pilot trying to land an emergency plane has great discretion in how they do so.

I guess this depends on your definition of responsible. Something like this however is bad enough that users should be informed right away so that they can take steps necessary to secure themselves. Assuming they were responsive I&#x27;d have given them the 10 days to confirm it was an actual issue, but I&#x27;d have expected them to notify the pubic and their users of the issue and mitigation steps within a week.

as demonstrated, &quot;responsible disclosure&quot; is a huge time waster for the discovery, and the price of this is undervalued even if the company had a clear bug bounty program.its more valuable than 90-days of a developer&#x27;s time, not even correlated to time at all really

If you want to test it without using your real webcam, I recommend CamTwist [1]. The author is in the group video call now. I joined for a short minute, and was relieved to see that my real webcam wasn&#x27;t being used.Normally I use CamTwist so I can write subtitles on top of my video feed when chatting with my gran. It seems it&#x27;s also a good layer of extra security![1] <a href="http:&#x2F;&#x2F;camtwiststudio.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;camtwiststudio.com&#x2F;</a>

WARNING, this will open a video chat with random strangers, and will turn your webcam on. Consider yourself warned!Amusingly enough, this actually exists as a product:<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Omegle" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Omegle</a>(Edit: just noticed it&#x27;s already been around for over 10 years. That&#x27;s rather amazing.)

Yes. Try this link from the article to see it in action if you have (or had) Zoom installed: <a href="https:&#x2F;&#x2F;jlleitschuh.org&#x2F;zoom_vulnerability_poc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jlleitschuh.org&#x2F;zoom_vulnerability_poc&#x2F;</a>WARNING, this will open a video chat with random strangers, and will turn your webcam on. Consider yourself warned!

&gt; In our Zoom clients, we both already had the “Turn off my video when joining a meeting” box checked.I believe this is one of the mitigations, which is why it didn’t work.

Personally, I do not think so.I did a test with myself and a coworker. I’m using macOS 10.12; he’s using 10.14. We both have up-to-date Zoom clients.In our Zoom clients, we both already had the “Turn off my video when joining a meeting” box checked.I set up a meeting, with participant video set to On, as the article describes. I took the new Meeting ID, launched Zoom, and joined my new meeting. I then sent my coworker the join URL using Slack.My coworker clicked on the link, which opened the URL in Safari. Safari asked my coworker if he wanted to launch Zoom. My coworker confirmed that yes, he wanted to launch Zoom.My coworker’s Zoom client did _not_ automatically start video. I never saw video come in from him.

10 years is nothing on the scale of language development, and SV is nothing on the scale of the English-speaking world :) Fear not, I bet there aren&#x27;t enough words to go around for this to be a big deal long-term.

&gt;The article does not clearly state this, ceding a plain English word to a corporation, enabling a takeover of human language.I agree with your outrage, but you have a long way to go. That sort of behavior is the soup du jour of SV the past ten years or so.Keep fighting the good fight. I&#x27;ve given up, but I hope you win.

that&#x27;s not a bug bounty, that&#x27;s reputation management

&gt; Offered and declined a financial bounty for the report due to policy on not being able to publicly disclose even after the vulnerability was patched.They seem to pay bug bounties if you agree to keep it down.

&gt;The article does not clearly state this, ceding a plain English word to a corporation, enabling a takeover of human language.The English language can handle it:proper noun- A noun belonging to the class of words used as names for unique individuals, events, or places.- A noun denoting a particular person, place, organization, ship, animal, event, or other individual entity.- A noun that denotes a particular thing; usually capitalized

I feel like selling bugs to the highest bidder is usually ethically questionable, no matter how “new” your viewpoint is.

They’re donating their expertise because, yes, this research is extremely valuable and important, but the vendor should obviously be paying for it.

I can&#x27;t imagine selling bugs to the highest bidder ever becoming ethically acceptable. You can&#x27;t pretend not to know that the high bidder is probably a cybercriminal. If you do this, your hat is clearly black.Once upon a time, vulnerabilities were just nuisances and people could justify some gray-hat casuistry when the damage was just some sysadmin overtime to clean up. But now there are serious organized crime rings and rogue nation-states using vulnerabilities to steal and extort billions and ruin people&#x27;s lives.It&#x27;s OK to choose not to work on products with no bug bounties, but if you do find a bug in one you must disclose it responsibly.

Beyond just a prevailing &quot;view&quot;, this duty to public safety is actually explicitly codified in the laws and regulations of most professional engineering organizations. To act otherwise would be a) unethical and subsequently b) grounds for loss of license to practice.

I would say the &#x27;first view&#x27; you&#x27;ve described is what the bulk of professionals in the information security industry would still espouse as the ideal.In my opinion this second view you are observing is carried by a vocal minority of participants in bug bounty programs and would be good fodder for a computer-ethics course.

The first view meets some sort of ideal (I guess) but causes all sorts of free riding problems. In larger society these sorts of problems are solved through regulations. For example if someone identifies a structural vulnerability in a bridge, the agency in charge of the bridge has a legal obligation to take steps to fix it. That sort of regulation doesn&#x27;t exist in software land.The second view as you describe it (selling to the highest bidder) is clearly black hat, but it is completely ethical for a researcher to disclose a vulnerability to the public if the vendor doesn&#x27;t fix it in a reasonable amount of time. So Project Zero and this disclosure are both fine. Yes, ordinary users may be harmed in the crossfire, but the vendor should be liable for damages.

Finally, note that Zoom effectively does not pay for bug bounties, so researchers should think twice about donating their expertise to a selfish for-profit corporationI&#x27;ve read this a few times and am curious if this has really become the prevailing view about what security researchers are doing (i.e., uncompensated labor) when they notify vendors about security vulnerabilities.The traditional view (which I think was widespread in the 90s or whatever) was that engineers who find vulnerabilities in products have a special responsibility to the public, and owe a duty to the people at risk: the users of the product (or whoever would be harmed if the vulnerability were exploited to malicious ends). Just like if you used your training as an engineer to discover that the Bay Bridge had a structural flaw and that drivers were at risk (or, in the case of Diane Hartley, that the new Citicorp Center had a design flaw and officeworkers were at risk). And this duty can be discharged a few ways, but often the most efficient way to help the people at risk is to educate the vendor and keep on their ass until they fix the problem in a free update. If the vendor pays you, fantastic, but you shouldn&#x27;t accept payment that would prevent you from discharging your duty to the people actually harmed by the vulnerability&#x27;s existence (e.g., if you take the vendor&#x27;s money and it comes with an indefinite NDA, and they never fix the problem and the users remain at risk of being harmed by bad actors forever, you have not behaved acceptably as an engineer). This view probably emerged at a time when bug-finders mostly had salaried jobs and were privileged not to have to depend on payments from the same vendors they were annoying with information on their product&#x27;s flaws.A newer view (probably informed by bug bounties, etc., and also a broader community of people doing this stuff) seems to &quot;no more free bugs for software vendors&quot; -- that researchers who find vulnerabilities in commercial products are producing knowledge that&#x27;s of value to the vendor, and the vendor ought to give them compensation for it, and if the vendor doesn&#x27;t want to do that, the researcher would basically just be doing uncompensated labor to give it to the vendor, and is free to go sell the fruits of their discovery to somebody who does value their labor instead. Even if that means selling the bug to unknown counterparties at auction and signing a forever NDA not to tell anybody else.The first view is mostly what we teach students in Stanford&#x27;s undergrad computer-ethics course and what I think is consistent with the rest of the literature on engineering ethics (and celebrated examples like Diane Hartley and William LeMessurier, etc.), but I do think it seems to be out-of-step with the prevailing view among contemporary vuln-finders. I&#x27;d love to find some reading where this is carefully discussed that we could assign students.

&gt; The article does not clearly state this, ceding a plain English word to a corporation, enabling a takeover of human language.English usually wins.

It&#x27;s pretty well known in white hat circles that Zoom has a paid private bounty program through one of the &quot;big 2&quot;. I know several who have got paid. Say what you like about non-disclosure, but it is the reality for most programs. We can disclose for pay, or disclose for fame, but usually not both.

Note: &quot;Zoom&quot; is a videoconfrerencing app, not a built-in Mac OS accessibility feature for &quot;zoom&quot;.The article does not clearly state this, ceding a plain English word to a corporation, enabling a takeover of human language.P.S.: This part&gt; Apr 26, 2019 — Video call with Mozilla and Zoom Security Teamsis funny, and would be way funnier if it was an non-consensual video call.Finally, note that Zoom effectively does not pay for bug bounties, so researchers should think twice about donating their expertise to a selfish for-profit corporation, and users should think twice about using a videochat product that allows its entire security team to take blackout vacations, and also doesn&#x27;t pay its outsourced sercurity researchers.

Indeed! It&#x27;s not even a hypothetical in this case. According to the article, Zoom was just 5 days away from letting one of the domains expire when the author told them.

Dangling domains happen all the time. As long as the main one that&#x27;s actually used is still controlled by the org, others can quite easily slip through the cracks, not renewed while still present in the codebase.

The article’s actual title is: Zoom Zero Day: 4+ Million Webcams &amp; maybe an RCE? Just get them to visit your website!But, assuming I’m reading it correctly, the “maybe an RCE?” part seems like fear-mongering, because it would require that Zoom lose control of one of the domains that they trust for transparent client installs&#x2F;upgrades.I’m also a little concerned about how some parts of the article don’t match up. For example, the “UPDATE: June 7th, 2019:” does not have (as far as I can see) a matching entry in the Timeline. There is an entry for July 7, noting a regression; but there is an update the next day (July 8) noting that the regression has been fixed.

This just in: Bad behavior is still bad behavior when it&#x27;s possible to mitigate it on the user side.Consider how many people use Zoom and don&#x27;t even know that Hacker News exists.

If you had a sandbox, you wouldn&#x27;t even need anyone to inspect it - since all the app&#x27;s files would be contained in one place, uninstalling it would remove everything, and there wouldn&#x27;t be a way to leave a server behind.

It silently reinstalls if you follow any Zoom meeting link.

This &quot;feature&quot;: <a href="https:&#x2F;&#x2F;apple.stackexchange.com&#x2F;questions&#x2F;358651&#x2F;unable-to-completely-uninstall-zoom-meeting-app" rel="nofollow">https:&#x2F;&#x2F;apple.stackexchange.com&#x2F;questions&#x2F;358651&#x2F;unable-to-c...</a>

Positively terrible... Kudos to this researcher. I liked Zoom when I used it a couple of times, but the reinstall “feature” is a huge violation of my trust. Software from the company behind it will not touch my system anymore. Too bad really, because properly working video chat is hard to find. The App Store model is not my favorite, but at times like these, a forced sandbox and inspection by a trusted third party start to look like the only way forward.

I would highly recommend visiting the proof-of-concept link, which is a Zoom videoconference hosted by the author full of people testing it out.

It does, but unfortunately without the -k flag.

Does osx not have the fuser command? It lets you find and kill a process by its tcp port (also file handles) in one command.On Linux I use something like &#x27;fuser -k 19421&#x2F;tcp&#x27; to kill server processes all the time. It is super useful when working with local dev servers etc!

From the article:&quot;To shut down the web server, run lsof -i :19421 to get the PID of the process, then do kill -9 [process number]. Then you can delete the ~&#x2F;.zoomus directory to remove the web server application files.&quot;

Really? That’s nuts. Makes you appreciate the iOS app model a bit more.Everything sandboxed, delete an app and all traces of it are gone.

What if you have uninstalled Zoom? It seems that it leaves a web server on your machine that will re-install Zoom if it receives a request to join a meeting.

How to protect yourself:&quot;Disable the ability for Zoom to turn on your webcam when joining a meeting.&quot;It&#x27;s under Settings-&gt;Video in Zoom, check &quot;Turn off my video when joining a meeting&quot;.

For the longest time the Linux client would just crash randomly. It also tends to heat up your laptop and use all of your cores at 100% if you&#x27;re looking at someone&#x27;s screen.Just run `strace -f zoom 2&gt; wtf.zoom` to see all of the shit it does (looks like it is polling for events like crazy).

I hadn&#x27;t heard of this, so I looked it up, and you are right:
<a href="https:&#x2F;&#x2F;www.exploit-db.com&#x2F;exploits&#x2F;43354" rel="nofollow">https:&#x2F;&#x2F;www.exploit-db.com&#x2F;exploits&#x2F;43354</a>At least that was patched. These sorts of issues are frustrating, because as a Linux user I really want to like Zoom -- I appreciate that the treat all platforms pretty equal (Mac, Windows, Linux, Android, iOS) with native apps. That is a rarity.

The Zoom client on Linux used to (?) have a nasty command injection. The URL for joining a meeting got passed to some bash reinvocation (so they could set the library path if my memory serves me). A specially crafted URL could execute commands on the system. I haven&#x27;t been too interested in using Zoom since seeing that.

I&#x27;ve opened up Safari and it properly asks me if I want to open slack when using: slack:&#x2F;&#x2F;test

When I clicked the PoC link in Safari, it launched the Zoom app using a URL scheme. (&quot;open in ...?&quot; dialog put up by Safari)

Oh, yeah, I missed that. That’s patently false.

That’s just false. Safari opens custom URIs.

below down the post, zoom team said that this feat exists because Safari doesn’t have custom url scheme.

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!

Am I the only one seeing the pattern here. Most security loop holes I have witness have existed at the cost of providing a better user experience.

&gt; The UX teamYou seem to imply that they have an UX team but not a security team, so nobody convinced anybody else that this wasn&#x27;t a good idea.Without genuine security orientation, even if an expert realizes there is a security problem, who wants to be the boring paranoid pessimist who wastes time and attempts to ruin products, only to be staved off by the efforts of more productive employees that focus on adding value?

A custom URI wouldn&#x27;t work as seamlessly as zoom&#x27;s UX team would have liked. If you hadn&#x27;t installed zoom, either a nasty message would tell you the protocol wasn&#x27;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 install or just redirect to the app.They broke so many security rules just to shave off a few inconvenient seconds, and those seconds rose them to the top.

A custom URL scheme would at least provide an opportunity to confirm launching Zoom, even if Zoom itself didn’t confirm joining s particular meeting (which I agree it should).

They put this in place precisely to avoid Safari&#x27;s &quot;Do you want to open this in Zoom&quot; confirmation prompt

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.

i didn&#x27;t see that. for me it just failed and to join a meeting now i need to open the zoom client and copy the meeting id manually. not a big deal for me, just wondering...

Yes, verified. Terminated and deleted ~&#x2F;.zoomus, links to join Zoom calls still open, but I am prompted to open Zoom first.

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

&gt; why the author says this is difficult to do securely? macOS has a simple facility for handling custom URL schemesSo does all other operating systems and this has been a thing for at least a couple of decades. This is not the problem.The problem is that this feature is severely locked down in all modern browsers, precisely due to the security risks involved.Relying on this feature in a critical user interaction path is a guaranteed way to get flooded with support-requests.Disclaimer: have replaced custom protocol with other solution in end-user facing production projects.

Citrix Workspace does exactly this and it works fine

I have some experience with this, you can use javascript on the <a href="https:&#x2F;&#x2F;" rel="nofollow">https:&#x2F;&#x2F;</a> meeting link to detect if the app protocol (zoom:&#x2F;&#x2F; or whatever) exists. If the app protocol exists then go straight to the app protocol link. If it doesn’t then prompt the user to download and install Zoom. The JS is a bit messy and requires a few different approaches but it works on all popular browsers on Windows and Mac (Linux support wasn’t needed, so not sure).Of course, the browser will pop up a confirmation dialog to ask if you want to open the Zoom app but this is a feature not a bug.

Universal Links are better than their localhost webserver insanity, but don&#x27;t really solve this. A malicious website can still redirect you to a zoom.us URL that will instantly join the meeting without confirmation.The underlying problem is that they want a URL to join a conference call hosted by any random user and share your audio&#x2F;video without confirmation. And it&#x27;s simply not safe to trigger that kind of action from a URL.

Universal Links will be supported on macOS Catalina. Reference: <a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;videos&#x2F;play&#x2F;wwdc2019&#x2F;717&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;videos&#x2F;play&#x2F;wwdc2019&#x2F;717&#x2F;</a>

If Universal Links was supported on macOS we could get the best of both worlds.The web server basically presents meta-data in a JSON-file (in the .well-known directory) which Safari&#x2F;iOS uses to launch the app if it is installed, and otherwise just renders the webpage [0].The app contains information about which domains it allows itself to be opened from which would fix this issue.[0]:<a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;library&#x2F;archive&#x2F;documentation&#x2F;General&#x2F;Conceptual&#x2F;AppSearch&#x2F;UniversalLinks.html" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;library&#x2F;archive&#x2F;documentation&#x2F;Ge...</a>

&gt; This vulnerability leverages the amazingly simple Zoom feature where you can just send anyone a meeting link (for example <a href="https:&#x2F;&#x2F;zoom.us&#x2F;j&#x2F;492468757" rel="nofollow">https:&#x2F;&#x2F;zoom.us&#x2F;j&#x2F;492468757</a>) 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 implemented securely. Nor can I figure out a good way to do this that doesn’t require an additional bit of user interaction to be secure.Does anybody understand (and have a moment to explain) why the author says this is difficult to do securely? macOS has a simple facility for handling custom URL schemes, so my impulse would be to have `<a href="https:&#x2F;&#x2F;zoom.us&#x2F;j&#x2F;492468757`" rel="nofollow">https:&#x2F;&#x2F;zoom.us&#x2F;j&#x2F;492468757`</a> do a server-side redirect to a URL like, say, `zoomus:&#x2F;&#x2F;492468757`, which would launch Zoom locally using the OS&#x27;s built-in services. This wouldn&#x27;t require a third-party daemon of any sort, and would just be a regular application that the user could trivially uninstall.Is there a security hole there that I&#x27;m missing? Or have I misunderstood the author&#x27;s point?

bluejeans video installs a nasty daemon that runs at boot too.  I&#x27;ll never attend a bluejeans meeting again

RingCentral Meetings uses zoom.us engine but the local server runs on port 19424 instead.
I&#x27;m able to replicate the issue on it.PoC: <a href="http:&#x2F;&#x2F;localhost:19424&#x2F;launch?action=join&amp;confno=3535353535" rel="nofollow">http:&#x2F;&#x2F;localhost:19424&#x2F;launch?action=join&amp;confno=3535353535</a>

Have your checked for similar vulnerabilities in competing products such as GoToMeeting and WebEx? They have the same basic features.

Great chat, I think you were right when you said all vulnerabilities should have a video conference for Q&amp;A after release. It was really helpful to get a better understanding of the platform and the threats facing it.

If you want to see some part of this fixed, please UPVOTE this issue:<a href="https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;standards-positions&#x2F;issues&#x2F;143" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;standards-positions&#x2F;issues&#x2F;143</a>

I listened for a long time, learned a lot as well.This made me think - is there any website that facilitates you to do such public conferences on zoom like clients. Basically a bunch of people who are interested in a certain topic could join and chime in - go from topic to topic. It could be a very healthy discussion. People could post and schedule meetings and essentially anyone who wants to learn could join. I do listen to podcasts often, but such meetings would be pretty different than podcasts.
Does this already exist?

Stayed on that call for over 3 hours and I just have to say that it was one of the best experiences I&#x27;ve had on the internet in years.People behaved pretty good considering it was a random public Zoom call (except for a few trolls, but nothing really bad).It just felt like the internet of yore where random people would meet and chat and just be nice to each other.Lots of interesting topics, people from all over the world, lots of surprised faces, random camera sights out the window, someone with a unicorn mask...It was a blast. Thank you Jonathan for a great time!

We need &quot;allow only for this session&quot; (or tab) in the permissions popup bar.

Huh, I&#x27;m on Windows and it auto-joined the meeting too, with video enabled. I wonder if this is because at some point in the past I opened a Zoom meeting and allowed Chrome to open the Zoom URI in the Zoom app?

&gt; You can confirm this server is present by running lsof -i :19421 in your terminal.Might be good to specify what the output would be if the vulnerability is present or not, like this:&quot;If the server is running on your machine, you&#x27;ll get a line specifying which process is listening to that port. If the command returns empty, your machine is not vulnerable.&quot;

It seems the web server &quot;is a workaround to a change introduced in Safari 12&quot;: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20389668" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20389668</a>&gt; You can ask your browser to remember the link associationIf that&#x27;s true in Safari, then a web server is using dynamite to kill a fly.

Interestingly, I implemented every mitigation listed in the article: kill the web server process, remove and add an empty directory at `~&#x2F;.zoomus` to prevent it being re-added, remove Firefox&#x27;s content type action for Zoom, and disable video turning on when Zoom launches. When I visit a Zoom join link or the POC link above, Firefox prompts me to open the Zoom client to join the meeting, and when I click &quot;Open Link&quot; the client opens just as it should and joins the meeting.This seems to confirm that there is no functionality to create a seamless experience for the user that actually requires the presence of the web server. If you don&#x27;t have the client installed the page can prompt you to download it the same as it would the very first time you download and install it. You can ask your browser to remember the link association and not be prompted for which app the link should open going forward. These are minor steps, even for a regular user, and ones with which most users are likely already familiar.To me this further illustrates that the web server is truly just a ploy on Zoom&#x27;s part to keep their hooks in users&#x27; systems, and have a way in that the user isn&#x27;t privy to. Any other excuse they are giving about &quot;enhanced experience&quot; is dubious at best and deceitful at worst.

Hi I&#x27;m the author, AMAOr come hang out in the party chat!Use the exploit to join:
<a href="https:&#x2F;&#x2F;jlleitschuh.org&#x2F;zoom_vulnerability_poc&#x2F;zoompwn_iframe.html" rel="nofollow">https:&#x2F;&#x2F;jlleitschuh.org&#x2F;zoom_vulnerability_poc&#x2F;zoompwn_ifram...</a>

yup, shocked me when i noticed. changed the name and unchecked the &#x27;remember name&#x27; feature. but it turns out that unchecking that will prefill the user account name, and next time the remember name feature is checked again. so that the only two choices are: either remember the name used last, or, if you uncheck it, have it fill in the account name.

Even if you have the camera disabled (and I never gave camera permissions to zoom to begin with), it will still join a random stranger&#x27;s meeting, which will leak your name (or whatever name you have configured). This may be important for some.

Huge kudos to the author for finding this security hole, reporting it responsibly, and then posting such a clear writeup.

They want to be able to re-install zoom for the user even if they have deleted it from &#x2F;Applications.

Ok, so the article says&quot;According to the Zoom team, the only reason this localhost server continues to exist is that Apple’s Safari doesn’t support URI handlers.&quot;Which is simply wrong. macOS (and i*OS) have supported custom URIs forever. What feature are they wanting? Do they want random websites to be able to install URI handlers?

Note that the server persists after the app is removed, so there’s that as well.Follow on: What are they talking about regarding custom url handlers? That’s a standard OS X feature...

Not sure why he didn&#x27;t just give us<pre><code> kill -9 $(lsof -i :19421)</code></pre>

I did this: 1. killed by process name, and zoom app will 2. fail to start its opener and 3. fail to reinstall it:<pre><code> killall ZoomOpener
 chmod -x .zoomus&#x2F;ZoomOpener.app&#x2F;Contents&#x2F;MacOS&#x2F;ZoomOpener
 sudo chown -R nobody:nobody .zoomus&#x2F;ZoomOpener.app</code></pre>

note the last part where the directory is removed (~&#x2F;.zoomus) and touch creates a file ~&#x2F;.zoomus. I am assuming a re-install will fail because it cannot create a directory again when there is already an existing file.My guess is that if sometime in the future you want to use zoom again, the install will fail until you remove the file ~&#x2F;.zoom

From the article:&gt; To shut down the web server, run lsof -i :19421 to get the PID of the process, then do kill -9 [process number]. Then you can delete the ~&#x2F;.zoomus directory to remove the web server application files.&gt; To prevent this server from being restored after updates you can execute the following in your terminal:rm -rf ~&#x2F;.zoomustouch ~&#x2F;.zoomus

And the upcoming pinebook pro: comes with a hardware privacy switch for camera, microphones and bluetooth&#x2F;wifi.For those who aren&#x27;t familiar with pinebooks, they&#x27;re $99 arm-based linux laptops.

some computers have this e.g. raspberry pi

I really wish physical switches that cut power to mics and cameras were standard on everything.I know that would be change from how hardware works &#x2F; is designed now but it also seems like the only reliable line of defense.

To allow meeting participants to use the web client to connect to a meeting requires the meeting host to explicitly enable the option in their advanced settings (it is disabled by default).

They do have a web client, but not WebRTC. See this reverse engineering of their protocol: <a href="https:&#x2F;&#x2F;webrtchacks.com&#x2F;zoom-avoids-using-webrtc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webrtchacks.com&#x2F;zoom-avoids-using-webrtc&#x2F;</a>TBH I don&#x27;t really understand their rationale. Nothing about it strikes me as &quot;better&quot; than WebRTC.

&quot;as far as I can tell the quality is indistinguishable from Zoom&quot;In my experience, the quality is similar to Meet when all parties have great internet connections. But if one or more parties has high&#x2F;variable latency or packet loss, then Zoom provides a much more smooth experience.

Not related to zoom, but I&#x27;m working with a team which uses &#x27;highfive&#x27;. I can&#x27;t, for the life of me, get the downloaded desktop app to ever work. There&#x27;s this perpetual dance of &quot;you need to be logged in&quot; and &quot;register now&quot; and &quot;log in&quot;. I was thinking it was something to do with the VPN, but it seems to be the same on or off. However, grabbing the full URL and pasting in to Chrome, works like a champ. I&#x27;d prefer to use the desktop app, but I can only get the browser version to work.

Google meet uses UDP: <a href="https:&#x2F;&#x2F;support.google.com&#x2F;a&#x2F;answer&#x2F;1279090?hl=en" rel="nofollow">https:&#x2F;&#x2F;support.google.com&#x2F;a&#x2F;answer&#x2F;1279090?hl=en</a>

WebRTC typically does use UDP. But it certainly isn&#x27;t as flexible as what you can do with a native app.

You can do so much better using a native app than a webapp. UDP transport is really important for real-time communication.

Why isn&#x27;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?

Yes, but blocking browser access to localhost from non localhost pages would stop the attack by simply visiting a webpage.It’s as much the fault of browsers for leaving the hole as Zoom for doing a shady job exploiting it.Very disappointed at Mozilla for their meh response.

&gt; The problem with asking permission is dialog fatigue and similar.That’s why I suggested config option and permission. There’s no dialog fatigue if you never see the dialog.That being said, there really ought to be a little menu of permissions that can be granted to a website such that the website cannot make it blink, flash, or otherwise draw attention to it. Crud like “allow push notifications” could go there. Granting push notification permission to a site is fine, but I don’t think sites should be able to ask for push notification permission.

The problem with asking permission is dialog fatigue and similar.As far as supporting local content: Historically a lot of terrible (read: Enterprise, H&amp;R Block tax software, etc) apps are glorified webpages, coupled with a local server that provides things like FS access and malware installation. Those apps use a kludge of remote and localhost urls, and generally expect to work.I suspect at this point though that browsers will just start going for the &quot;no access to localhost&quot; route as this practice is mercifully dying out (alas in favor of Electron apps shipping full, but out of date, browsers).To me the bigger problem is: Zoom installed a server on a machine, without consent, with the ability to install software (without consent). Removing the browser&#x27;s access to that service doesn&#x27;t mean anything because an attacker can always just directly attack the server.Even if the server locks connections to exclusively coming from localhost they&#x27;ve provided a service that can install and launch software, which can therefore be used as a sandbox escape - e.g a super constrained network service gets compromised - the idea is that service can&#x27;t modify the filesystem or what have you, but now it can just connect to localhost and get a file written to disk.People keep on complaining about apple &quot;locking down the system&quot;, but its because of developers like Zoom that Apple needs to do this: and average user is not going to see this post, and Zoom has clearly decided that it is in their interests to leave a service running that can install software for them.I hope that apple drops the XProtect hammer on the server binary, and the ban hammer on their signing cert.

I don’t get Mozilla and Chromium’s responses. I can think of few cases in which a website should be allowed to issue requests (CORS, img, or otherwise) to an address on the local network and none whatsoever in which a website should be able to contact localhost.The fix seems straightforward. Require user permission to access the local network (subject to appropriate heuristics as to what “local” means). Require a config option and user permission to access localhost. Problem solved.

Not having to cede control to the user. If the user wanted&#x2F;wants your software they know how to install software at this point. They also have a much better mental model of what that means.

Not having to cede control of the experience to the system, presumably.

macOS and iOS both support custom schemes, and have done forever. What feature does Zoom actually want?

The browsers allows anything according to the CORS configuration on the target website. Perhaps it would be a good idea to prompt for access to localhost&#x2F;127.* resources.

Yep. This[0] post[1] from a few months ago touched on this with more discussion.[0] <a href="http:&#x2F;&#x2F;http.jameshfisher.com&#x2F;2019&#x2F;05&#x2F;26&#x2F;i-can-see-your-local-web-servers&#x2F;" rel="nofollow">http:&#x2F;&#x2F;http.jameshfisher.com&#x2F;2019&#x2F;05&#x2F;26&#x2F;i-can-see-your-local...</a>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20028108" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20028108</a>

&gt;&lt;img src=&quot;<a href="http:&#x2F;&#x2F;localhost:xxxxx&#x2F;launch?action=join&amp;confno=492468757&quot;&#x2F;&gt;" rel="nofollow">http:&#x2F;&#x2F;localhost:xxxxx&#x2F;launch?action=join&amp;confno=492468757&quot;&#x2F;...</a>So a browser allows a random remote website access to stuff running on the localhost interface? Is this a good idea? Stuff like camera access I can at least disable...

Yeah. That&#x27;s why I bought a webcam cover. I highly recommend if you don&#x27;t have one already.

What’s the issue? That VDCAssistant keeps running for a bit?

That seems like an OS daemon specific to the built in webcam.<a href="https:&#x2F;&#x2F;www.cnet.com&#x2F;how-to&#x2F;fix-no-connected-camera-error-on-your-mac&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cnet.com&#x2F;how-to&#x2F;fix-no-connected-camera-error-on...</a>&gt; When you run a program that uses your Mac&#x27;s webcam, OS X will launch a background process called VDCAssistant, which manages the connection and control of the camera. While this process should quit when the program stops using the camera, it may persist if an error occurs, and prevent future connections to the camera, either by the same program or by others.

Ok here&#x27;s the thing. Open Google Hangouts, or any other website that asks for permission to use your webcam, then close the tab. Go to terminal check if VDCAssistant is running using `lsof | grep -i VDC` it returns that it is running. I&#x27;ve had this issue since 2015 so I&#x27;m glad someone is talking about this now.. Is it just me?

Its installs are not incremental. How many versions of GTM are currently installed on your computer? Last time I cleaned it up, I had six.

I&#x27;m curious what your objection is to GTM. I&#x27;ve been using it for a decade and have really come to see it as the only reliable option for us.

GoToMeeting and Zoom are two things I always insist not to use. There are perfectly acceptable online-only counterparts that don&#x27;t need to infect my computer.

It probably helps if I explain what I linked...Micro Snitch is a small MacOS toolbar application which runs in the background looking for system calls made to the camera or the microphone. It visually indicates when either are being used and logs the activity to a file for future review.

Might I suggest: <a href="https:&#x2F;&#x2F;www.obdev.at&#x2F;products&#x2F;microsnitch&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;www.obdev.at&#x2F;products&#x2F;microsnitch&#x2F;index.html</a>

Surprised something of this magnitude seems to have 0 impact on stock price after hours.

I tested the repro-steps and found that the ZoomHelper was not listening, although it was installed . In this case i was prompted to download zoom.pkg rather than activate video.I&#x27;m guessing it was because I have MacOS firewall = strict (no listening ports)Also, here&#x27;s a nice tip to show all listening apps (good habit while cleaning up)<pre><code> lsof -i -s tcp:listen |awk &#x27;{print $1 &quot; &quot;$8&quot; &quot; $9}&#x27;|sort|uniq
 COMMAND NODE NAME
 Google UDP *:mdns
 SystemUIS UDP *:*
 SystemUIS UDP *:53611
 UserEvent UDP *:*
 WiFiAgent UDP *:*
 identitys UDP *:*
 rapportd TCP *:49152
 rapportd UDP *:*
 sharingd UDP *:*</code></pre>

Do you know if this vulnerability might manifest in other ways, and permit remote participants to force you into sharing or viewing your screen silently?One of the first times I&#x27;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&#x27;t asked) seemed nearly verbatim to my written notes.

It says that the server sends an image with certain dimensions back as an error code, so I wonder what you could do if you served some simple HTML that uses the local server as a meta tag that renders in the preview?I imagine slack would do that on the client since it’s built on electron.Unless it requires more than loading a URL.

I wonder if this works in an electron app (like Slack maybe) displaying it?Maybe you could intentionally send this link to someone shown as inactive on Slack, and have the WSlack webpage preview thing run enough javascript to pop open Zoom with the camera and mic running...I&#x27;d test it myself, but I deleted Zoom and the sneaky localhost web server while I read the article...

&gt; Activate the Zoom link and hope the person is AFK. Spy on their home&#x2F;office&#x2F;whatever. Also a violation.I think this is the most likely scenario. There are ways you could potentially delay it (e.g. they leave a tab open and you don&#x27;t open the link until a certain time)

Scenario 3:  You want to be a jerk and put someone into a meeting they weren’t in to get them in trouble.

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&#x27;s an unsecured API that responds with an image. You can trivially embed it in anything that renders HTML.

I&#x27;m trying to think of the real-world implications and how this would play out.Normally this would be pretty obvious, wouldn&#x27;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&#x2F;mic. If it can do that and stay in the background, all bets are off.In spite of its obviousness, it&#x27;s still pretty darn scary --Scenario 1: malicious website&#x2F;app opens link while you&#x27;re sitting there.You&#x27;re sitting in front of your computer, you see Zoom open, you&#x27;re like &quot;WTF?!&quot;, 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&#x2F;app delays opening the link until some threshold of mouse&#x2F;KB inactivity is reached.Activate the Zoom link and hope the person is AFK. Spy on their home&#x2F;office&#x2F;whatever. Also a violation.Are there other scenarios I am missing?Personal note 1: I&#x27;m happy I switched to a Linux laptop after finding last year&#x27;s MBPs disappointing (and the TB revolting; I have a physical escape key!).Personal note 2: I do actually like Zoom a lot, it&#x27;s an awesome video conferencing app. But this should be fixed for Mac users.

Investors would care if they thought Zoom’s customers cared enough to switch. I personally think this is terrible, but investors don’t seem to think Zoom’s customers care enough to change to a competitor, which makes me second guess whether or not this is actually a big deal to large customers.

Tavis Ormandy joked about buying those dips because of this and I really don&#x27;t think either of you are wrong and I might start doing it myself.

Stock markets very rarely care about security, unless it&#x27;s somehow front page news.

If a company’s stock drops after a major vulnerability, you should buy. Equifax exposed everyone’s financial data and their stock is back above their pre-breach price.

This feels material, which is why I’m surprised there’s 0 movement in their stock price after hours. Why do you think that is?

how does it work ? because we do larger conference calls with a distributed team of 40 people. As in - is there a paid plan, etcalso, does it work with mobile apps ?

Jitsi Meet is also an excellent web-based video conferencing tool. They also have a basic comparison of WebRTC vs Zoom [0] which is actually has the same demonstration video as your second article. I posted a basic overview elsewhere in this thread [1], and I would strongly recommend it.[0]: <a href="https:&#x2F;&#x2F;jitsi.org&#x2F;news&#x2F;a-simple-congestion-test-for-zoom&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jitsi.org&#x2F;news&#x2F;a-simple-congestion-test-for-zoom&#x2F;</a>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20390149" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20390149</a>

Why is the web client (on Chrome, etc) so bad on Zoom ? I mean, people are building Google Earth on the browser .Its not just the bad video experience - even the product experience is seriously broken.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 - <a href="https:&#x2F;&#x2F;webrtchacks.com&#x2F;zoom-avoids-using-webrtc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webrtchacks.com&#x2F;zoom-avoids-using-webrtc&#x2F;</a><a href="https:&#x2F;&#x2F;bloggeek.me&#x2F;webrtc-vs-zoom-video-quality&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bloggeek.me&#x2F;webrtc-vs-zoom-video-quality&#x2F;</a>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.

Can confirm, CORS (Origin: ramdomsite.tld to localhost) works just fine in Chrome.If you have a CORS enable server on localhost you can make requests to it from <a href="http:&#x2F;&#x2F;www.test-cors.org" rel="nofollow">http:&#x2F;&#x2F;www.test-cors.org</a>

You&#x27;re 100% correct, and while someone has pointed out the proper headers that need to be set on the bug report here: <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=67743" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=67743</a>, it&#x27;s been drowned out by people who don&#x27;t seem to understand the issue:<a href="http:&#x2F;&#x2F;williambert.online&#x2F;2013&#x2F;06&#x2F;allow-cors-with-localhost-in-chrome&#x2F;" rel="nofollow">http:&#x2F;&#x2F;williambert.online&#x2F;2013&#x2F;06&#x2F;allow-cors-with-localhost-...</a>CORS is hard, I&#x27;ve struggled on it several times, and I&#x27;m not surprised an engineer gave up trying to fix it because of deadlines.

That&#x27;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.

Am I right in thinking that CORS only applies to Javascript-initiated requests? This trick uses an embedded image to make the request.

Not sure I follow the CORS angle. The linked stackoverflow question mostly seemed to be someone who was confused about how CORS works, and the issue in the Google Chrome tracker was closed as WontFix because they couldn&#x27;t reproduce it and said it should work.I&#x27;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&#x27;t that is much worse IMO...

It&#x27;s pretty convenient for Zoom that this occurs after the IPO.

I choose white for mine! It matches better I think. :)

It always makes me wonder why people keep tape on camera sensor but don&#x27;t care about microphones. Maybe I&#x27;m wrong but I think things you and other people around say can be of more value to the attacker than what you do or how you look like.

Zoom is why my shiny 27&quot; Retina iMac is decorated with a small square of black electrical tape.

Long live the App Store - developers, customers, Apple.

Zoom allow iframing the join page as well? Why are they not seeing X-Frame-Options‽

Here&#x27;s a small script you can run to mitigate the issues described in the article: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;notmyname&#x2F;824db39350e3d39496de2ea930a56f63" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;notmyname&#x2F;824db39350e3d39496de2ea930...</a>

Refusing to install software for video calls is a good policy. Also, having a throwaway workstation for such things (also Skype, which is spyware of the worst kind) is useful too, for when it’s a pre-sales call and security can’t outweigh closing a six+ figure deal.

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&#x27;s watching but what you have no control over is the microphone

&gt; what type of work do you do that uses the video for portions other than the presentation?My department (of 400 people) is split between two cities. I am regularly in meetings with people from the other city.Google Meet is a big part of our culture. It helps with team cohesion and collaboration to actually see each other&#x27;s faces when we meet.It is of course not _required_ but I really believe it is better than just audio.

You weren&#x27;t asking me, but I run into this same thing.In my business -- project management software -- I&#x27;m in online meetings a LOT (say, 20 hours a week?) because everyone in my company is remote. We have never, ever used video. It just doesn&#x27;t come up. Nobody wants it internally, and none of our customers ask for it in external meetings. I don&#x27;t think any of them use it internally, either (and many of our customers are large, distributed organizations with offices all over the place).This seems normal to me.My neighbor is an IT VP for a health care concern. She travels a lot (30-40%), and when she&#x27;s home she&#x27;s in online meetings pretty much all the time. And in her company, video is ALWAYS included. I have no idea why, and neither does she; it&#x27;s a cultural thing.The upshot, though, is that I work in t-shirts and cargo shorts, and she has to be &quot;office ready&quot; even though she works at home. However, I will note that, if I run into her outside when she&#x27;s walking the dog, it&#x27;s not unusual to see her in a nice blouse, hair and makeup done, but wearing yoga pants or whatever. Which is its own kind of hilarious.

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.

To ubermonkey&#x27;s point, some of this can be a company culture thing.Certain teams at my workplace use webcams all the time, others never. My team leverages them quite a bit, as our team is all over the world. It helped solidify our team members not just as random voices on a phone line, but as actual people who we will likely never meet in person.

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?

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&#x2F;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 devices - camera, microphone, USB etc - and I use that for web surfing.And I strictly don&#x27;t install any plugins for video calls. I have refused to join meetings where people try to make me install random binary software on my machine. There&#x27;s always phone call for such situations.I feel better about dedicated apps on iPhone where again I can install and grant permissions before the call and then uninstall the app completely. On iPhone I don&#x27;t do any web surfing. I have Firefox Focus for occasional emergencies to open the unknown web.

I don&#x27;t know what you mean by &quot;still&quot;. Apparently it was software disable-able up to the 2011 mbps.

Has anyone torn down recent-era Macbooks to see if the camera LED is still hardwired to the camera power and a reliable indicator that can&#x27;t be software disabled?

I know it&#x27;s said in jest but the trusty screwdriver lays itself in a lot more permanent solution.

What blows my mind the most about all of this is how such a successful company has managed to engineer such a shitty solution to this very common problem. I’m not even speaking from a security standpoint (which is a catastrophe) but this feels like some holier than though neckbeard wanting to literally reinvent the wheel on everything. Encoding enum’s as images served from a local web server with various pixel widths??? You can’t make this up. I never liked their UX and now I guess I don’t like what’s under the hood either. Good riddance.

Blog post too, which seems to be somewhat different: <a href="https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-on-concern&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-...</a>

Zoom&#x27;s official response to this issue: <a href="https:&#x2F;&#x2F;assets.zoom.us&#x2F;docs&#x2F;pdf&#x2F;Zoom+Response+Video-On+Vulnerability.pdf" rel="nofollow">https:&#x2F;&#x2F;assets.zoom.us&#x2F;docs&#x2F;pdf&#x2F;Zoom+Response+Video-On+Vulne...</a>

It looks like it can also happen if you simply open an HTML email with Apple Mail: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;funjon&#x2F;status&#x2F;1148464952480374784" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;funjon&#x2F;status&#x2F;1148464952480374784</a>

By being blind to the implications.The most charitable interpretation of the Superhuman read-receipt problem is kinda the same thing: they had an idea, thought it was good, and then did some deeply shitty things to make it work. And nobody at Zoom or at Superhuman had the organizational power to stop it.

Hosting a web server on localhost is the equivalent of adding a backdoor on your customer&#x27;s machines. How does a product team even reach this decision?

I use uMatrix, and I&#x27;ve seen localhost show up as a domain a site tried to connect to quite a few times. I never gave it too much thought since I block all non-first-party resources by default anyway, but I now realise it could indicate the use of tricks like this to attempt to communicate with some other process running on my computer. I&#x27;ll now make sure to look closer whenever I see this. I bet Zoom isn&#x27;t the only one doing things like this.

That&#x27;s a hard problem to solve. An audio alert that the microphone has turned on would obviously be rejected by consumers, unless maybe some fancy processing were used to remove that alert sound from the recording. But even so, an audio alert would presumably only play once while the indicator light remains illuminated the entire time.On the other hand while an indicator light is good for the camera, it&#x27;s not sufficient for audio. If the computer is facing away from me, then the camera can&#x27;t see me so my inability to see the camera light isn&#x27;t that huge of a deal. But audio goes around corners so I could be recorded by a computer not immediately in eyesight.If there were some reasonable third sensory channel to available for &quot;out of band&quot; communication, that would be ideal. But consumers will reject smell-alerts.

id much rather the zoom conference can&#x27;t do anything unless I let it

A hacker could turn the light on and off before you even knew what to do about it. All they need is a picture of your face to do something nefarious.

If you do this audio-only there isn’t a telltale LED on the camera to give away that you are doing it.  I’m way more worried about audio bugging than a webcam (which really only has the user’s face)

AFAIK the light is controlled by the camera&#x27;s firmware. So unless someone is able to hack that, the light will always turn on with the camera. That said, even Zuckerberg has sticky tape over his camera.

One assumes that this activates the green camera light? It&#x27;s not perfect but I can&#x27;t imagine not noticing that it had come on.Not that it helps if you&#x27;re, ahem, in the middle of something when the nefarious 3rd party opens the line.

No amount of security features can rival a small piece of black tape over the camera.It also makes crypto-phishing (you&#x27;ve been recorded doing X, pay Y BTC) much harder to fall for. Where software could (and eventually will) be compromised, the attacker would have to physically access the machine to remove that tape.

I guess he reported to Chrome first because that’s what everybody uses, found their answer (or lack of answer) unsatisfactory, and then went to report to Firefox.

&gt; Apr 10, 2019 — Vulnerability disclosed to Chromium security team.&gt; Apr 19, 2019 — Vulnerability disclosed to Mozilla FireFox security team.Does anyone have any idea why there was a 9 day delay between disclosure to Chromium and Firefox teams?

Those little tricks to make things easier is why it&#x27;s popular  and why they&#x27;re currently valued at $25,000,000,000 (though that should go down quite a bit tomorrow, still just an insane number for a company with $8m in annual profits).

you forgot one more thing: they don&#x27;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&#x27;t have it installed)

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&#x27;s security policies, supposedly because &quot;it is their key differentiator&quot; or whatever.Basically their product managers decided they wanted it to work a certain way and demanded someone do whatever nasty hacks were necessary to make it happen.It turns out their nasty hack doesn&#x27;t set the proper CORS policy so any random webpage can force you to join a meeting.It also turns out they don&#x27;t do what mac apps are supposed to do: keep this crap inside the app bundle so dragging the app to the trash effectively uninstalls everything. Instead they install to ~&#x2F;.zoomus, don&#x27;t document that fact, and if you hit a zoom link after &quot;uninstalling&quot; they automatically reinstall themselves.Oh and they let the registration for one of their domains expire and nearly lost control of it, which would make this a RCE because their client doesn&#x27;t do anything to validate their update packages as far as anyone can tell.I think that about covers it?

Why isn&#x27;t the Windows client vulnerable? What have they&#x2F;Microsoft done differently?

Yeah, this seems like it must violate some Apple TOS, right? The uninstaller leaves behind a local webserver, that can&#x27;t possibly be allowed.

Yeah, when I read this, I said WAT.How on earth does Apple allow this ? I&#x27;m not excusing Zoom, but this is Apples fault.

I realised I had a paid account, so I&#x27;ve cancelled that too.  And I&#x27;ve also reported them to Apple, after seeing that the ZoomOpener app reinstalls the client - which is completely and utterly unacceptable.

What a glorious response. “Your product is broken.” “We know, we did it on purpose, and we’re proud of it!”

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

&gt; I wonder if the reason will make it through the corporate fogI really doubt it. Given the change control policies of huge corps and how awful it is to get anything new&#x2F;get rid of anything they&#x27;ll just toe the zoom party line and keep it.

&gt; I think they need to be made aware that this isn&#x27;t acceptable.Oh, definitely. I cancelled my subscription because of this, but I wonder if the reason will make it through the corporate fog.What is worrying is that more and more companies think it is fine to install &quot;helpers&quot;, &quot;openers&quot; and other cruft. I recently removed several, and I still have to use software that scares me sometimes (DYMO web printing, Brother web printing). This should not be considered OK.

I asked Zoom support about this and they sent me to this page: <a href="https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-on-concern&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-...</a>The key thing here is they think this is a fair trade-off because Safari asks if you want to open Zoom.&gt; 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.I do not believe that this is a fair trade-off given that any website can act on this locally installed server.EDIT: I think they need to be made aware that this isn&#x27;t acceptable. My reply to their support team: 
I do not believe this is a fair trade-off - allowing any arbitrary web site local control of privileged software installed on my machine - because Safari offers a security prompt (specifically so that any arbitrary web site does not gain control of privileged software on my machine). I will be switching ~&#x2F;.zoomus&#x2F;ZoomOpener.app off, and considering other options until it has been fixed.

It is not possible to hack these:<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;HTR-WCB1-Web-Camera-Blocker&#x2F;dp&#x2F;B005953IRI" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;HTR-WCB1-Web-Camera-Blocker&#x2F;dp&#x2F;B00595...</a>

The most damning part of the conclusions:&gt; This being said, I also recommend that any researcher that finds a vulnerability in Zoom’s software does not directly report the vulnerability to Zoom. Instead, I recommend that researchers report these vulnerabilities via the Zero Day Initiative (ZDI). The ZDI disclosure program gives vendors 120 days to resolve the vulnerability, the ZDI will pay researchers for their work, and researchers have the ability to publicly disclose their findings.

That part just doesn’t seem very responsive. Unless Zoom is recommending that everyone should turn it OFF, and urgently releasing a patch to make OFF the default, why does it matter that the vulnerability is in an optional feature rather than a mandatory one?

That is a pre-existing feature, and while it mitigates one specific aspect of the issue, it doesn&#x27;t represent a security-focused response. Yes, I am saying that&#x27;s not good enough: an appropriate, non-dismissive response would commit to writing code to deal with the issue raised, subject to the industry standard 90-day embargo. Depending on how much importance they place on their user&#x27;s security.

&gt; All first-time Zoom users, upon joining their first meeting from a given device, are asked whether they would like their video to be turned OFF. For subsequent meetings, users can configure their client video settings to turn OFF video when joining a meeting. 
&gt; Additionally, system administrators can pre-configure video settings for supported devices at the time of install or change the configuration at anytime.TBH, they&#x27;re not as dismissive as you&#x27;re sounding them to be

Also, they seem almost entirely focused on &quot;unwittingly joining a meeting&quot; 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&#x27;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 &quot;update&quot; that uninstalls zoom entirely. In a nastier one, they used this idiotic design flaw to pwn every zoom client machine out there.

Some kind of NDA terms are not unheard-of. Like a 1-3 month period in which to work on things during which disclosures won&#x27;t go out.That said, there&#x27;s a slight disconnect between Zoom&#x27;s two statements here. The first is that the researcher declined out of concerns over Zoom&#x27;s NDA. The second is that NDAs are common. What this doesn&#x27;t say is that Zoom&#x27;s NDA is cookie-cutter or what the specific terms are.If I were to guess, Zoom was using some unusual NDA and attempting to buy permanent silence.

Will they pay the rest of your team and your spouse as well?  &quot;I&#x27;ve already sent these results to a few colleagues around the world to test out, but don&#x27;t worry, they won&#x27;t disclose anything for 90 days&quot;.

&gt; Zoom invited the researcher to join our private paid bug bounty program, which he declined because of non-disclosure terms. It is common industry practice to require non-disclosure for private bug bounty programs.Is an NDA really &quot;common industry practice&quot; for bug bounty programs? I know NDAs are common for pen-testing but it seems like an odd (and kind of dishonest) requirement for a bug bounty program.

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.&gt; 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 probably fine&gt; Also of note, we have no indication that this has ever happened.* Other products have the same vulnerability&gt; We are not alone among video conferencing providers in implementing this solution.* We decided not to fix it&gt; Ultimately, Zoom decided not to change the application functionalityAnd also a lovely one I haven’t seen before:* We tried to buy the researcher’s silence, but he refused&gt; Upon his initial communication to Zoom, the researcher asked whether Zoom provides bounties for security vulnerability submissions. Zoom invited the researcher to join our private paid bug bounty program, which he declined because of non-disclosure terms. It is common industry practice to require non-disclosure for private bug bounty programs.1. <a href="https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-on-concern&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.zoom.us&#x2F;wordpress&#x2F;2019&#x2F;07&#x2F;08&#x2F;response-to-video-...</a>

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