“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!”
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.
This server is still running on my machine despite having "removed" 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's instructions on how to uninstall the app on macOS just points to documentation from Apple and wikiHow (???) with standard methods that don't fully remove Zoom.
I'm sure Zoom intentionally failed to tell you how to remove the web server. After all, if it's still running, then it's just that much easier to reinstall Zoom on your machine.
Does anyone know how this web server starts itself after restarting your machine? As far as I know, a `~/.zoomus` directory can't restart a web server after your machine restarts.
It doesn'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 -> Users & 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.
as demonstrated, "responsible disclosure" 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's time, not even correlated to time at all really
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'd have given them the 10 days to confirm it was an actual issue, but I'd have expected them to notify the pubic and their users of the issue and mitigation steps within a week.
> users should be informed right away so that they can take steps necessary to secure themselves
For the record, this could be accomplished by a trustworthy source announcing "there is a critical vulnerability in Zoom's macOS software and you should uninstall it immediately pending vendor response". Some researchers do this already -- Tavis Ormandy has, for example.
It's not a binary choice between no disclosure and releasing an unpatched PoC.
By the way, I'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.
Unfortunately in this case "uninstall it immediately" does not actually mitigate the vulnerability, since it will just reinstall itself if you come across a triggering link.
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'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's also a good layer of extra security!
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.
The default is that the box is unchecked - i.e. the Zoom client will, by default, automatically turn on your camera when you join a meeting. You can opt out of that behavior by checking this box, but that behavior is the default.
Note: "Zoom" is a videoconfrerencing app, not a built-in Mac OS accessibility feature for "zoom".
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
> Apr 26, 2019 — Video call with Mozilla and Zoom Security Teams
is 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't pay its outsourced sercurity researchers.
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't enough words to go around for this to be a big deal long-term.
> 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.
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
I'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't accept payment that would prevent you from discharging your duty to the people actually harmed by the vulnerability's existence (e.g., if you take the vendor'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's flaws.
A newer view (probably informed by bug bounties, etc., and also a broader community of people doing this stuff) seems to "no more free bugs for software vendors" -- that researchers who find vulnerabilities in commercial products are producing knowledge that's of value to the vendor, and the vendor ought to give them compensation for it, and if the vendor doesn'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'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'd love to find some reading where this is carefully discussed that we could assign students.
I can't imagine selling bugs to the highest bidder ever becoming ethically acceptable. You can'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's lives.
It'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.
While most people agree selling a vulnerability is immoral, there is much debate on whether "full disclosure" is ok, and whether "responsible disclosure" is a term anyone should ever say (some argue the correct term is "coordinated disclosure").
Beyond just a prevailing "view", 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 'first view' you'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'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'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.
It's pretty well known in white hat circles that Zoom has a paid private bounty program through one of the "big 2". 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.
The article’s actual title is: Zoom Zero Day: 4+ Million Webcams & 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/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.
Dangling domains happen all the time. As long as the main one that'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.
Indeed! It'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.
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.
If you had a sandbox, you wouldn't even need anyone to inspect it - since all the app's files would be contained in one place, uninstalling it would remove everything, and there wouldn't be a way to leave a server behind.
Right, I agree! My point is that preventing this situation from happening in the first place, through better sandboxing restrictions, is both more fair and more effective than having each app be individually approved. If you try to mitigate this just with app review, then 1) you're going to miss apps that do bad things, and 2) It introduces huge conflicts of interest for the reviewer. But if you were to have effective sandboxing, it wouldn't be possible for Zoom or any other app to do this in the first place, so that you would be able to trust the apps that you install even if they haven't been reviewed.
"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 ~/.zoomus directory to remove the web server application files."
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.
macOS is gradually adopting that starting with Catalina, e.g. System Extensions (that will replace Kernel Extensions) and DriverKit drivers too I assume, are installed with app bundles and uninstalled when the app is trashed.
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't been too interested in using Zoom since seeing that.
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're looking at someone's screen.
Just run `strace -f zoom 2> wtf.zoom` to see all of the shit it does (looks like it is polling for events like crazy).
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.
> 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 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 `https://zoom.us/j/492468757` do a server-side redirect to a URL like, say, `zoomus://492468757`, which would launch Zoom locally using the OS's built-in services. This wouldn'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'm missing? Or have I misunderstood the author's point?
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 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.
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!
If you want to really break down their viewpoint on the situation, lets translate their PR statement line by line:
> 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.
Oh come on. There is no easy way to send people without the app to a installer page, that is the issue. And that is something every single person wants.
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.
They have the opposite starting with Catalina and iOS, Universal Links that lets an app register to take the first pass at handling zoom.us URLs. Android always had this with their intent system.
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 <a href="zoom://12345" handler="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
Those are some interesting points. I'm not convinced that versions should be in scope for this sort of thing though. If I'm writing a protocol handler, I think it's my responsibility to make sure my software can update itself, and make the default behavior that it should check for updates if it is given a URI it doesn't understand.
Secondly, version checks assume that the user wants to run this specific protocol handler. I as the user might prefer to run an open source non-official zoom client. I think the OS should only be trying to help me if I don't have any handler.
Well, presumably if that's the case, their ZoomOpener could simply be configured to respond that it exists. That would be enough to either direct the user to a download page or open the protocol-specific URI.
If I'm understanding it correctly, the reason it does more than that is to bypass the "protocol-specific URI opening" UX.
I'm unclear what subset of users are desktop only Zoom users that aren't also familiar with the same "Do you want to allow this app to access your camera/microphone?" dialogs on mobile devices. This can't be a large demographic, can it?
In fairness, I get irritated about the fact I need to tell WebEx to use my computer's audio to join the call every damn time I join a meeting quite annoying.
If only there was some happy middle ground between never asking and always asking ...
This is the pattern of applications continuing to be deeply flawed and heavily advertised as long as you can be bought for a billion by IBM/Microsoft/Google/Facebook/TechOverlorfOfTheYear and finally get into a stable enough state so that they can be part of the infrastructure when a full-features open source version emerges.
Yeah, it's a tradeoff by nature. This applies to security in general, not just computers. Having to unlock the door to your house when your hands are full with shopping is annoying, but the alternative is leaving your house unlocked all the time and trusting nobody will walk in.
Depending on the context (location, is there usually someone home anyway, value of stuff within the house) you may or may not find the tradeoff makes sense and voluntarily opt for the worse 'UX'.
As I understand it, they tried to design a new plane that wouldn't require pilots to be re-trained on how to use it, if they'd already been trained on an older model. That's the UX I'm referring to.
The fun thing is users mistakenly recognise the tradeoff as a sign of the security. If it was annoying it must be secure. Why would somebody waste my time for no purpose? See also placebo effect - of course I feel better, you gave me pills and I took them, duh, it's medicine.
You seem to imply that they have an UX team but not a security team, so nobody convinced anybody else that this wasn'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 sustainable company isn't built on velocity, lack of conflict, and willful ignorance.
Decisions need to be made between strong opinions about the right path forward. There needs to be balance and respect between these aspects.
Reading the PR statement, I highly doubt the people who have those strong opinions about security are being given a fair voice. They are probably there, but they have zero power to change anything within their product.
I think literally every VC isn't built to be sustainable, they are designed to randomly jab the marketplace for a good investment bet. I wouldn't even expect them to listen to this kind of advice, it doesn't apply :)
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.
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).
i didn'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...
I have some experience with this, you can use javascript on the https:// meeting link to detect if the app protocol (zoom:// 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.
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/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.
Universal Links are better than their localhost webserver insanity, but don'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/video without confirmation. And it's simply not safe to trigger that kind of action from a URL.
I can confirm that this vulnerability exists in RingCentral for macOS, version 7.0.136380.0312.
I was taken into Miguel's meeting, but since the host wasn't presented, it simply let me know it was waiting for him (It also had a friendly notice "Your video will turn ON automatically when the meeting starts".
I've changed my settings in Video > Meetings, just like in Zoom, to turn off my vid when joining. Also confirmed that the server is running on port 19424 (via terminal command 'lsof -i :19424').
Great chat, I think you were right when you said all vulnerabilities should have a video conference for Q&A after release. It was really helpful to get a better understanding of the platform and the threats facing it.
Stayed on that call for over 3 hours and I just have to say that it was one of the best experiences I'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!
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?
I am not aware of anything like what you describe, but I did see some people in that Zoom call suggesting the creation of a Discord and/or Slack channels.
However what I fear is that they will become like any other modern forum in that you will need heavy moderation, people will try to troll, etc.
The beautiful thing about Jonathan's call was it's spontaneity I think, and that everyone was so excited to talk about the vulnerability that the group had a single focus.
I might be too cynical so maybe it's a good idea, and if someone suggest a place/site/forum to have these kind of discussions I would definitely try it out.
Huh, I'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?
> 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:
"If the server is running on your machine, you'll get a line specifying which process is listening to that port. If the command returns empty, your machine is not vulnerable."
Interestingly, I implemented every mitigation listed in the article: kill the web server process, remove and add an empty directory at `~/.zoomus` to prevent it being re-added, remove Firefox'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 "Open Link" 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'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's part to keep their hooks in users' systems, and have a way in that the user isn't privy to. Any other excuse they are giving about "enhanced experience" is dubious at best and deceitful at worst.
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's meeting, which will leak your name (or whatever name you have configured). This may be important for some.
yup, shocked me when i noticed. changed the name and unchecked the 'remember name' 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.
"According to the Zoom team, the only reason this localhost server continues to exist is that Apple’s Safari doesn’t support URI handlers."
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?
> 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 ~/.zoomus directory to remove the web server application files.
> To prevent this server from being restored after updates you can execute the following in your terminal:
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 internet address
":19421" = local machine, port 19421
I think they're missing a "-t" on lsof, to make it output process IDs only ("terse mode") instead of a human-readable table:
Doing it that way results in a nuisance prompt from Zoom every time you launch it complaining that it can't launch the opener.
Here's a modified version that deletes the app, removes the LoginItem if it exists, and makes the ~/.zoomus directory unwritable, which achieves the same thing but avoids the nag:
note the last part where the directory is removed (~/.zoomus) and touch creates a file ~/.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 ~/.zoom
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?
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).
"as far as I can tell the quality is indistinguishable from Zoom"
In my experience, the quality is similar to Meet when all parties have great internet connections. But if one or more parties has high/variable latency or packet loss, then Zoom provides a much more smooth experience.
Not related to zoom, but I'm working with a team which uses 'highfive'. I can't, for the life of me, get the downloaded desktop app to ever work. There's this perpetual dance of "you need to be logged in" and "register now" and "log in". 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'd prefer to use the desktop app, but I can only get the browser version to work.
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.
The problem with asking permission is dialog fatigue and similar.
As far as supporting local content: Historically a lot of terrible (read: Enterprise, H&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 "no access to localhost" 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's access to that service doesn'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'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'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 "locking down the system", 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.
They have a web server on your machine. If the browsers did that, they would find some other way to handle this since they have a server running on your computer.
I don't think the browser vendors are to blame here.
> 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.
In my experience if you tell users "to use this awesome thing, you need to enable this option", a reasonable portion will do it.
It sounds like what you're saying is that there should be a dialog, but only if you've already enabled a setting, which raises the question of "if this feature is so bad you don't want it exposed, why would you have it available at all?".
Not having to cede control to the user. If the user wanted/wants your software they know how to install software at this point. They also have a much better mental model of what that means.
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...
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/127.* resources.
Ok here'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've had this issue since 2015 so I'm glad someone is talking about this now.. Is it just me?
> When you run a program that uses your Mac'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.
GoToMeeting and Zoom are two things I always insist not to use. There are perfectly acceptable online-only counterparts that don't need to infect my computer.
472 comments
[ 5.1 ms ] story [ 287 ms ] thread...
“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!”
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's instructions on how to uninstall the app on macOS just points to documentation from Apple and wikiHow (???) with standard methods that don't fully remove Zoom.
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.
its more valuable than 90-days of a developer's time, not even correlated to time at all really
For the record, this could be accomplished by a trustworthy source announcing "there is a critical vulnerability in Zoom's macOS software and you should uninstall it immediately pending vendor response". Some researchers do this already -- Tavis Ormandy has, for example.
It's not a binary choice between no disclosure and releasing an unpatched PoC.
By the way, I'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.
WARNING, this will open a video chat with random strangers, and will turn your webcam on. Consider yourself warned!
Normally I use CamTwist so I can write subtitles on top of my video feed when chatting with my gran. It seems it's also a good layer of extra security!
[1] http://camtwiststudio.com/
Amusingly enough, this actually exists as a product:
https://en.wikipedia.org/wiki/Omegle
(Edit: just noticed it's already been around for over 10 years. That's rather amazing.)
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.
I believe this is one of the mitigations, which is why it didn’t work.
The box says “Turn off my video...”. So, I think having it on by default is a good thing.
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
> Apr 26, 2019 — Video call with Mozilla and Zoom Security Teams
is 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't pay its outsourced sercurity researchers.
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've given up, but I hope you win.
They seem to pay bug bounties if you agree to keep it down.
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'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't accept payment that would prevent you from discharging your duty to the people actually harmed by the vulnerability's existence (e.g., if you take the vendor'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's flaws.
A newer view (probably informed by bug bounties, etc., and also a broader community of people doing this stuff) seems to "no more free bugs for software vendors" -- that researchers who find vulnerabilities in commercial products are producing knowledge that's of value to the vendor, and the vendor ought to give them compensation for it, and if the vendor doesn'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'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'd love to find some reading where this is carefully discussed that we could assign students.
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's lives.
It'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.
While most people agree selling a vulnerability is immoral, there is much debate on whether "full disclosure" is ok, and whether "responsible disclosure" is a term anyone should ever say (some argue the correct term is "coordinated disclosure").
https://news.ycombinator.com/item?id=18233897
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 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'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.
English usually wins.
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/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.
Consider how many people use Zoom and don't even know that Hacker News exists.
"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 ~/.zoomus directory to remove the web server application files."
On Linux I use something like 'fuser -k 19421/tcp' to kill server processes all the time. It is super useful when working with local dev servers etc!
"Disable the ability for Zoom to turn on your webcam when joining a meeting."
It's under Settings->Video in Zoom, check "Turn off my video when joining a meeting".
Everything sandboxed, delete an app and all traces of it are gone.
Just run `strace -f zoom 2> wtf.zoom` to see all of the shit it does (looks like it is polling for events like crazy).
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.
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 `https://zoom.us/j/492468757` do a server-side redirect to a URL like, say, `zoomus://492468757`, which would launch Zoom locally using the OS's built-in services. This wouldn'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'm missing? Or have I misunderstood the author's point?
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.
> 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.
* 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
Secondly, version checks assume that the user wants to run this specific protocol handler. I as the user might prefer to run an open source non-official zoom client. I think the OS should only be trying to help me if I don't have any handler.
If I'm understanding it correctly, the reason it does more than that is to bypass the "protocol-specific URI opening" UX.
If only there was some happy middle ground between never asking and always asking ...
I'd be totally fine with default-on voip sound - with a red, muted mic button and a bubble saying 'tap to unmute'.
Depending on the context (location, is there usually someone home anyway, value of stuff within the house) you may or may not find the tradeoff makes sense and voluntarily opt for the worse 'UX'.
I'd argue the moral of that story was to redesign the plane, instead of piling on hacks to save costs in the short run.
You seem to imply that they have an UX team but not a security team, so nobody convinced anybody else that this wasn'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?
Decisions need to be made between strong opinions about the right path forward. There needs to be balance and respect between these aspects.
Reading the PR statement, I highly doubt the people who have those strong opinions about security are being given a fair voice. They are probably there, but they have zero power to change anything within their product.
> Decisions need to be made between strong opinions about the right path forward. There needs to be balance and respect between these aspects.
tell that to literally every VC
So yeah, sounds like one human, and it sounds like she/he probably doesn't have much say.
So 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.
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.
The web server basically presents meta-data in a JSON-file (in the .well-known directory) which Safari/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]:https://developer.apple.com/library/archive/documentation/Ge...
The underlying problem is that they want a URL to join a conference call hosted by any random user and share your audio/video without confirmation. And it's simply not safe to trigger that kind of action from a URL.
However, I do think that Universal Links doesn't work with redirects, consider: https://bit.ly/30oxOdO vs https://twitter.com/ycombinator (tap using Safari on iOS with Twitter installed).
EDIT: Turns out I was misinformed...
Or come hang out in the party chat!
Use the exploit to join: https://jlleitschuh.org/zoom_vulnerability_poc/zoompwn_ifram...
launchctl list
Then you need to find where the plist files are (i.e. com.bluejeans.app.detector.plist).
You can disable an entry from launchctl list:
launchctl disable uid/<your user uid>/com.bluejeans.app.detector
You can also unload if you find the actual file
launchctl unload ~/Library/LaunchAgents/com.bluejeans.app.detector.plist
There were a couple differently named bluejeans agents.
PoC: http://localhost:19424/launch?action=join&confno=3535353535
I was taken into Miguel's meeting, but since the host wasn't presented, it simply let me know it was waiting for him (It also had a friendly notice "Your video will turn ON automatically when the meeting starts".
I've changed my settings in Video > Meetings, just like in Zoom, to turn off my vid when joining. Also confirmed that the server is running on port 19424 (via terminal command 'lsof -i :19424').
https://github.com/mozilla/standards-positions/issues/143
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!
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?
However what I fear is that they will become like any other modern forum in that you will need heavy moderation, people will try to troll, etc.
The beautiful thing about Jonathan's call was it's spontaneity I think, and that everyone was so excited to talk about the vulnerability that the group had a single focus.
I might be too cynical so maybe it's a good idea, and if someone suggest a place/site/forum to have these kind of discussions I would definitely try it out.
Might be good to specify what the output would be if the vulnerability is present or not, like this:
"If the server is running on your machine, you'll get a line specifying which process is listening to that port. If the command returns empty, your machine is not vulnerable."
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'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's part to keep their hooks in users' systems, and have a way in that the user isn't privy to. Any other excuse they are giving about "enhanced experience" is dubious at best and deceitful at worst.
> You can ask your browser to remember the link association
If that's true in Safari, then a web server is using dynamite to kill a fly.
Follow on: What are they talking about regarding custom url handlers? That’s a standard OS X feature...
"According to the Zoom team, the only reason this localhost server continues to exist is that Apple’s Safari doesn’t support URI handlers."
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?
> 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 ~/.zoomus directory to remove the web server application files.
> To prevent this server from being restored after updates you can execute the following in your terminal:
rm -rf ~/.zoomus
touch ~/.zoomus
"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 internet address
":19421" = local machine, port 19421
I think they're missing a "-t" on lsof, to make it output process IDs only ("terse mode") instead of a human-readable table:
Here's a modified version that deletes the app, removes the LoginItem if it exists, and makes the ~/.zoomus directory unwritable, which achieves the same thing but avoids the nag:
My guess is that if sometime in the future you want to use zoom again, the install will fail until you remove the file ~/.zoom
I know that would be change from how hardware works / is designed now but it also seems like the only reliable line of defense.
For those who aren't familiar with pinebooks, they're $99 arm-based linux laptops.
TBH I don't really understand their rationale. Nothing about it strikes me as "better" than WebRTC.
In my experience, the quality is similar to Meet when all parties have great internet connections. But if one or more parties has high/variable latency or packet loss, then Zoom provides a much more smooth experience.
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.
As far as supporting local content: Historically a lot of terrible (read: Enterprise, H&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 "no access to localhost" 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's access to that service doesn'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'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'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 "locking down the system", 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.
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.
I don't think the browser vendors are to blame here.
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.
It sounds like what you're saying is that there should be a dialog, but only if you've already enabled a setting, which raises the question of "if this feature is so bad you don't want it exposed, why would you have it available at all?".
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...
[0] http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...
[1] https://news.ycombinator.com/item?id=20028108
https://www.cnet.com/how-to/fix-no-connected-camera-error-on...
> When you run a program that uses your Mac'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.