Zoom Vulnerabilities
Jonathan Leitschuh (Hacker News, Reddit):
A vulnerability in the Mac Zoom Client allows any malicious website to enable your camera without your permission. The flaw potentially exposes up to 750,000 companies around the world that use Zoom to conduct day-to-day business.
[…]
Additionally, if you’ve ever installed the Zoom client and then uninstalled it, you still have a
localhost
web server on your machine that will happily re-install the Zoom client for you, without requiring any user interaction on your behalf besides visiting a webpage. This re-install ‘feature’ continues to work to this day.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.
The problem lies is how Zoom allows whoever sets up the call—be that someone creating a conference call for a company, or perhaps a hacker—to decide whether participants’ webcams are enabled at the start of the call or not. Leitschuh says Zoom did fix this, and stopped an attacker from turning on a user’s video camera, but then an issue with the patch was discovered, still allowing a hacker to turn on the camera.
Second, when Zoom is installed on a Mac device by the user, a limited-functionality web server that can only respond to requests from the local machine is also installed on the device to help launch Zoom meetings. 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 wonder if, rather than “Safari 12,” he means “Safari in macOS 10.12,” as that was the version that introduced the incredibly annoying confirmation alert every time you click a link to another app. It doesn’t just prompt you the first time for a particular app, or the first time a link from a certain site takes you to that app; it asks you every single time. I have to click through these alerts dozens of times a day, and after years of this you can be sure that I don’t read them.
If this Safari security feature had not been so draconian, I doubt that Zoom and similar apps would have gone to such lengths to work around it. And I have serious doubts that the alert actually helps security much, both because of the limited ways such links could be abused and because I don’t think most users are able to make an informed decision about it.
Frankly, everyone looks bad here. Zoom, obviously, because of questionable design decisions and poor engineering. And Apple, because this is the type of app that should be in the Mac App Store. Whenever someone would send me a Zoom link, I would try to find another way to communicate because I didn’t want to run their installer and figure out how to remove any junk that it added. Were the app in the Mac App Store, I would have easily installed it and trusted that it was confined to its container. Technically, the app should be able to do everything it needs within the sandbox. But for whatever reason—perhaps business—Zoom didn’t find the Mac App Store to be a good way to distribute its app.
The solution is not to further lock down apps outside the store, making both users and developers miserable. Think about what types of lock down would have been required to prevent this and whether it would have actually been effective. (Are you going to ban local Web servers? Try to discourage the user from clicking Allow?) No, the solution is to make the store more attractive so that it makes sense for mainstream apps—from indies to multi-billion dollar companies like Zoom—to be there.
This sucks, and I am upset with Zoom, but am I correct in thinking if this happened I could just immediately quit the zoom app? I mean the zoom app isn’t exactly stealthy. Also, maybe I might be more worried about it sharing my screen than the camera, is it doing that?
The flipside to responsible disclosure: failure to patch a critical vulnerability in 90 days makes a software vendor irresponsible and it’s a good thing for their irresponsibility to become public knowledge sooner than later
Oh hey, Zoom is that product that installs the entire app inside its package preflight script if it detects that you’re running as administrator. Naughty indeed.
If you don’t like how Zoom bypasses safari security wait till you see how Google Chrome proxies USB / HID clients 🤭
What other apps install local web servers that always run, even when the app is not running, even after you’ve uninstalled the app?
For instance, is that you @figmadesign? 😔
I also found that, instead of making a regular AJAX request, this page instead loads an image from the Zoom web server that is locally running. The different dimensions of the image dictate the error/status code of the server...One question I asked is, why is this web server returning this data encoded in the dimensions of an image file? The reason is, it’s done to bypass Cross-Origin Resource Sharing (CORS).
You know the state of video conferencing apps is bad when “it might turn on your camera without your permission” isn’t bad enough to make you switch to one of the worse alternatives.
To check to see if the Web server is running, open Terminal, enter this command, and press Return:
lsof -i :19421[…]
If you want to get rid of the hidden Web server, though, you’ll have to use Terminal.
Zoom nastiness removal one-liner. Open Terminal, paste and press return:
lsof -i TCP:19421 | awk 'NR > 1 {print $2}' | xargs kill -9; rm -rf ~/.zoomus; touch ~/.zoomus
I don’t pretend to follow all of Leitschuh’s explanation of the vulnerability, but I do understand the commands for the fix. I thought I’d talk about what they do. Also, there’s a cut-and-paste solution getting some traction on Twitter that I want to talk about.
Previously:
Update (2019-07-11): Jason Snell:
I think this Zoom story is getting a bit overhyped, but the fact is that Apple added a security feature that required an extra click by the user, and @zoom_us responded by... installing a local web server to bypass the feature. Talk about a disproportionate response.
My guess is that Zoom’s original sin comes out of its corporate culture, which is focused on competing in a pretty cutthroat industry with demanding clients (IT managers) and not particularly technically literate customers (the individual business users). There’s probably a great fear of losing business to other businesses who can boast about running video meetings with ever less friction to the user.
Zoom had a cascading failure of product decisions, security bypasses, and then a terrible hand-waving blog post—which has been updated several times, and they’re finally doing the right thing.
This reminds me of the 2005 Sony rootkit scandal. Zoom had no ill intent here, but they scored own goals by allowing developers to create a system that intentionally bypasses security protections, installs unknown software, and has no consent involved.
But the fact that Zoom implemented it in a way such that the web server was still there, still running, even when you deleted the Zoom app, is morally criminal, and should be legally criminal. No one who understands how this worked could possibly have thought this was ethical.
Yes, @zoom_us is a garbage fire that deserves to go bankrupt. But we need to analyse why they do this: it’s because macOS doesn’t provide the frameworks & infrastructure to implement these features in a simple & secure way.
Ideally, macOS would work more like iOS, where developers could bundle specific extensions within their bundles that the system would register and launch on demand for these purposes. Instead, they have to work around these limitations in an atrocious way.
The Safari security feature that requires user-confirmation will always stop drive-by [no user interaction] attacks. Attacks that are designed to passively launch exploits.
In Catalina, apps can use universal links + associated domains to avoid the confirmation dialog.
I’ve taken those [uninstall] commands and used them to build a script to address the vulnerabilities described in CVE-2019-13450.
Zoom (Hacker News):
We are stopping the use of a local web server on Mac devices. Once the patch is deployed, Mac users will be prompted in the Zoom user interface (UI) to update their client. Once the update is complete, the local web server will be completely removed on that device. 2. Allow users to manually uninstall Zoom – We’re adding a new option to the Zoom menu bar that will allow users to manually and completely uninstall the Zoom client, including the local web server. Once the patch is deployed, a new menu option will appear that says, “Uninstall Zoom.” By clicking that button, Zoom will be completely removed from the user’s device along with the user’s saved settings.
Apple has released a silent update for Mac users removing a vulnerable component in Zoom, the popular video conferencing app, which allowed websites to automatically add a user to a video call without their permission.
So the Zoom story seems to be mostly over. However, there remain some open questions:
Why didn’t Zoom use a Safari extension to avoid the extra click? Would it not have done the job? Did they not consider this option? Did they deem it too clunky for customers to install and enable?
Is the browser the appropriate place to put these sort of protections? After all, potentially dangerous links can be received via other means, such as e-mail and iMessage. Would it make more sense for the app receiving the link to offer protection? For example, FaceTime requires you to click a button to answer a call (though Apple lets it bypass asking for camera access). There could be a preference—off by default—to auto-accept connections, or to only auto-accept from certain trusted callers.
What does Apple consider to be the actual problem—opening custom links in response to user action, or only drive-by attacks?
Will Universal Links in macOS 10.15 make a difference? It sounds like the answer is only in some cases.
Why aren’t people talking about BlueJeans, which runs a similar daemon for similar reasons?
Will browsers continue to allow remote pages to access local servers? That seems to be the root problem in this case.
Update (2019-07-12): Jonathan Leitschuh:
That @zoom_us daemon (hidden web server) is now known to have a Remote Code Execution Vulnerability!
Zoom: Let’s allow remote access to your mic/cam 🛡️ OverSight: Fine, but we’ll detect & alert
Apple: Let’s silently remove Zoom 🛡️ BlockBlock: Fine, but we’ll detect & alert
Update (2019-07-16): Juli Clover:
Apple today pushed a second silent security update to Macs to address further vulnerabilities related to the Zoom video conferencing app for macOS, reports The Verge.
Apple removed software that was installed by RingCentral and Zhumu, two video conferencing apps that relied on technology from Zoom and were also found to have the same vulnerabilities as Zoom earlier this week.
Update (2019-07-17): Rich Trouton:
To verify that you have this installed, here’s a one-line command to check for the latest installed MRT installer package[…]
This option is enabled by default — even if you choose to install regular system updates manually — which is why the vast majority of Mac users are getting these “silent” updates automatically. But if you disable this option, even these silent updates won’t be installed automatically. I confirmed this with an Apple spokesperson, who emphasized that Apple only issues such updates “extremely judiciously”. Any pending security updates will be installed the next time you manually update software.
[…]
If I could tweak anything, it would be to have these updates show up in the regular list of pending software updates if you have “Install system data files and security updates” turned off.
This is why we disclose vulnerabilities. Now, finally, Zoom is taking this seriously and fixing it for real.
Update (2019-07-25): See also: The Talk Show.
The current zoom installer for macOS installs and runs the application from a pre-install script in the installer package. Also, if you use the “pkginfo” option with installer command to get info about the package, it also installs and runs. 😫😫😫😫
11 Comments RSS · Twitter
I don't know that I find Safari's policy that draconian. Certainly, I wouldn't be opposed to a "don't bother checkbox", but I *really* find it annoying when another app jumps to the front and I don't expect it. Sometimes it's just about being ready or wanting to delay an app opening, but sometimes you accidentally click on a URL...
Aside from all this, zoom could have chosen to build a rather simple Safari extension to accomplish their goals. Heck, they could even use an extension to deliver something more integrated like they do for Chrome, if they wanted.
@Michael The lack of Safari extension is certainly interesting, and I would like to hear their explanation. I was assuming that was unsuitable for some reason, as it seems so much easier to develop than what they ended up doing. If Safari extensions could really intercept links like that, StopTheNews could be a Safari extension and avoid the problem with t.co links.
I think a Safari extension would actually work. The difference is that Zoom would control *both* the extension and the web site. Safari extensions don't get to handle URL redirects, which is why it wouldn't work for StopTheNews, but those redirects are occurring at the behest of Apple and Twitter, which are entirely outside a third party extension's control. Zoom's own web site could tell its own extension to open its app.
@Jeff Thanks for explaining that. I guess the downside (for Zoom) is that there’s no way to fully automate installing and enabling a Safari extension?
@Michael True. You can bundle an extension with the app, but the user has to manually enable the extension in Safari Preferences.
I was just going to apply the incantations and followed Dr Drang instructions. When launching the zoom app to make sure I had the right pref, I was greeted with an update notification (likely not Sparkle, or if it is, then they purposedly make it look very ugly). Here are the release notes:
Release notes of 4.4.53932.0709:
Remove local web server
-We are discontinuing the use of a local web server on Mac devices. Following the update, the local web server will be completely removed from the Zoom installation
Option to uninstall Zoom
-Zoom users can now uninstall the Zoom desktop application and all of its components through the settings menu
After the update, the command `lsof -i :19421` returns empty, and the full list of open files from just `lsof` does not include any apparent Zoom stuff.
Looks like the easiest way to fix this issue is to update, though I will remain very suspicious.
By the way, Zoom also installs and enables a login item. Not sure what it's doing but I removed that as well.
[…] tell whether the app is going to abuse the power it’s given. If I’m installing Zoom, of course I’m going to grant it access to the camera. That’s reasonable for an app of […]
[…] Eine sehr ausführliche Liste an Links zu diesem Problem ist bei Michael Tsai zu finden: https://mjtsai.com/blog/2019/07/09/zoom-vulnerabilities/ […]