Everything is on fire

Just in case you’re not reading about the latest security implosion, (does that even mean anything any more? It’s not like it’s rare), Zoom, a GoToMeeting clone decided that “convenience” outweighed all concerns, including any form of common sense, professional ethics and sanity. Here’s the best, most detailed writeup from the guy who discovered it. It’s long, but read it anyway.

By “convenience” I mean, they didn’t want to do the “hard” UI/UX work to make their app actually easy to use. No, instead, they just made it effectively impossible to fully uninstall without some command-line time, and made it so it could stealth reinstall at any time if you clicked on a web link. If the person building the “meeting” decided your camera should be on when you “joined”, your camera was on. Brilliant. How convenient. Totally not creepy or bad at all.

I mean, they actually viewed having to click a button a worse sin than not giving you a choice. But, you could go into the Zoom client and in the settings turn the “your camera automatically comes on when you join a meeting” off. Because that’s what most non-tech people do, instantly traverse (regularly awful to use) app preferences on a newly installed application to set it up. Ow, my eye-rolling muscles just cramped. This is literally the worse sort of “opt-out as default” behavior, but hey, convenience. For Zoom that is.

So yeah, Zoom. Who, without warning, or explanation, installed a hidden webserver on your mac. Not “oops, we forget to tell you”, but actually hidden. (You don’t name the directory “.zoomus” if you aren’t trying to hide it. That’s the only reason to start a file/directory name with a period. Period.) What was the purpose of this webserver? Why to automatically reinstall the Zoom client if you clicked on the right kind of link. Of course, that only worked from a series of trusted domains. And it’s not like Zoom would accidentally almost let one of those domains go up for grabs…

Doing a whois lookup on all of the domains listed in the source code returned some interesting results. For example, the domain zoomgov.com was scheduled to expire on May 1st, 2019. Had this domain registration been allowed to lapse, the takeover of this domain would have allowed an attacker to host an infected version of the Zoom installer from this site and infected users who had uninstalled Zoom from their computers. Essentially, this would have made this vulnerability a Remote Code Execution (RCE) vulnerability. I disclosed this bit of information to the Zoom team during my call with the Mozilla security team on April 26th, 2019. Within 5 hours of the end of that call that domain had been registered out to May 1st, 2024.

…oops…

But it’s really easy to manually fix this. Delete the app, then just run these two terminal commands:

pkill "ZoomOpener"; rm -rf ~/.zoomus; touch ~/.zoomus && chmod 000 ~/.zoomus;
pkill "RingCentralOpener"; rm -rf ~/.ringcentralopener; touch ~/.ringcentralopener && chmod 000 ~/.ringcentralopener;

and bob’s your uncle. For some value of “bob” and “uncle”. The sad thing is, Zoom didn’t even begin to think of the badness of this until they were getting beaten up over it. No, really, here: https://blog.zoom.us/wordpress/2019/07/08/response-to-video-on-concern/

Some choice quotes:

There are two matters also brought up in this inquiry that deserve to be addressed.

First, a local denial of service (DOS) vulnerability for Mac devices. In this vulnerability, a hacker could potentially target a Mac user who already has Zoom installed with an endless loop of meeting join requests, effectively causing the targeted machine to lock up. Again, we have no indication that this ever happened. We released a fix for this in May 2019, though we did not force our users to update because it is empirically a low-risk vulnerability.

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.

Oh. My. God. They are literally doing the “You can’t fuss at me for kicking a puppy because Billy punched a baby” thing. A software company pulling out little kid logic. Also, given the amount of security thought they put in their product, I don’t think I’m taking their definition of low risk seriously. Also, really, having to click a button is some kind of awful thing? Just how many Zoom meetings are people getting invited to where clicking a “you sure you want to do this” button is some kind of awful punishment?

Let me restate this: they stealth-installed a hidden webserver to circumvent built-in security in the name of “convenience”. The application defaults allow a remote meeting creator to turn your camera and mic on without warning. There are not enough letters in “bullshit” to describe the bullshit of this bullshit. And then, when they released a patch, they didn’t even try to push it out. A younger me would be screaming. Current me is just sighing, because current me sees this all the time.

Another one:

This week, a researcher published an article raising concerns about our video experience. His concern is that if an attacker is able to trick a target Zoom user into clicking a web link to the attacker’s Zoom meeting ID URL, the target user could unknowingly join the attacker’s Zoom meeting. If the user has not configured their Zoom client to disable video upon joining meetings, the attacker may be able to view the user’s video feed. Of note, we have no indication that this has ever happened.

Yeah skeezix, that’s how security researchers work. They tell you things before they get abused. That’s kind of the point. It’s why you should listen to them. (Not that security researchers are paragons of ethical behavior. But that’s a post for another time.)

And this one:

We do not currently have an easy way to help a user delete both the Zoom client and also the Zoom local web server app on Mac that launches our client.  The user needs to manually locate and delete those two apps for now. This was an honest oversight. As such, by this weekend we will introduce a new Uninstaller App for Mac to help the user easily delete both apps.

This was not an honest oversight, because the way to actually make uninstalling the entire app easy would have been to place everything in the application bundle, so when the human deleted the app, poof, all gone. This is not hidden master developer knowledge. It’s pretty common stuff and important for actual ease of use for the person who is using the app. Oh, and doing this means you don’t need an Uninstaller App that you have to install next to your app. Doing it the right way actually saves you work. Wow, imagine that.

This was a deliberate design decision whose point was to make it hard to fully uninstall the app. Don’t front my dude.

Finally:

We appreciate the hard work of the security researcher in identifying security concerns on our platform. Initially, we did not see the web server or video-on posture as significant risks to our customers and, in fact, felt that these were essential to our seamless join process. But in hearing the outcry from some of our users and the security community in the past 24 hours, we have decided to make the updates to our service. In response to these concerns, here are details surrounding tonight’s planned Zoom patch and our scheduled July release this weekend:

If Zoom seriously did not see the potential problem in the web server, the defaults, or their application file layout scheme, then they are a company with all the security awareness of a brick, the people at Zoom making decisions are stupid to the point of appearing malicious, and you should most emphatically never use their software, because this will not be the last time stupidity at this level happens.

The fact it took a multi-day internet flogging to get them to see the light doesn’t make it any better.

However…

That’s not the main point of this post. (If you are a new reader, I am a verbose kind of person. I wallow in it. You may wish to get used to that.)

The point is, this is why Apple is going crazy about UAC (and why they need to add more to it. Like network port usage.) Because in the Linux “it’s up to you to do everything” world, there’s no way in hell a non-technical user would be able to fix this. They’d not know what to look for, how to look for it and they certainly wouldn’t think to use:

pkill "ZoomOpener"; rm -rf ~/.zoomus; touch ~/.zoomus && chmod 000 ~/.zoomus;
pkill "RingCentralOpener"; rm -rf ~/.ringcentralopener; touch ~/.ringcentralopener && chmod 000 ~/.ringcentralopener;

Which is actually a series of commands ganged together:

pkill "ZoomOpener"
rm -rf ~/.zoomus
touch ~/.zoomus
chmod 000 ~/.zoomus
pkill "RingCentralOpener"
rm -rf ~/.ringcentralopener
touch ~/.ringcentralopener
chmod 000 ~/.ringcentralopener

Honest to god, it’s a good thing Zoom’s devs were kind of incompetent in how they hid their stuff. If they’d really wanted to hide it well, non-technical users would be nuking and paving forever because they’d keep reinstalling the Zoom client and having this happen again. I mean, even half-assing it could cause this, but at least it’s vaguely easy to find it.

The idea that guarding against this kind of crap is all up to the user and things like advanced UAC and SIP and the new read-only system volume coming in Catalina are “bad” or limiting freedom is an idea that is elitist at its core. It says “if you just want to use a computer, bad things will happen to you and it will all be your fault.” Note that computers are the only place we say this. If you told people that they had to know everything about vehicle design to ride a bus or drive a car safely, and if they didn’t, then any defects in the vehicle that harmed them were their fault, not the manufacturer’s, those same techno-libertarians would shit themselves to lighten their weight load so they could get to protesting faster.

Even worse, ponder doing that for aviation. Don’t know the difference between a safe level of speed-tape on an engine and a “don’t get on that plane, you’re gonna die” level? Don’t know what speed-tape is? Sucks to be you.

No one would ever fly again, and they would be correct to never fly again. But when it’s a computer? Oh well, it’s the user’s job to be a sysadmin/senior dev. It’s certainly not anyone else’s job to protect the user from predatory crap like that.

Zoom is not unique here, not even close. I’ve been seeing this kind of crap happen for decades. And the response, when the dev is caught is the same as Zoom’s. I cannot, literally can. not. recall an instance where the dev didn’t try to justify it, to somehow try to blame the people who caught them. To pull the “well, it’s not a real problem” crap. To pull all the dodges that somehow absolve them of any real fault.

Apple may not always implement things the best way the first time around, but they are doing more to make things safe to use by default than literally anyone else. Every time I see someone gripe about their new UAC in a new macOS release, it’s never “there’s a better way.” It is always, always “I find this inconvenient.”

Yeah, well I find having to help family members accept that their stuff has been destroyed because a dev didn’t give a crap and hoping they have a backup to be inconvenient.

The kind of “we don’t want to do things that are inconvenient for us, screw the user” attitude, so extensively on display here for Zoom has to end. There is a limit, eventually, and I think even Apple is getting close to it, on how much the OS vendor can do to protect people from a dev determined to do this kind of shit. At some point, we, the user community, have to be more angry at the devs pulling this crap than at the OS vendor who “allows” it. When an app installs a rootkit, whether or not the OS should have allowed that is a secondary point. The fact the dev decided to take that action is the real offense.

If someone kicks in my door and robs my house, I may be mildly annoyed at the door manufacturer for making a weak door, but the real offender is the person who broke into my house. When devs shove bullshit adware frameworks into their apps, it is they who are the worst offenders, not Google/Microsoft/Apple for not preventing them. It is the asshole’s fault, first and foremost for being an asshole. Zoom, in this instance, is the asshole, and based on what I see coming from them, they don’t really think they screwed up, but they would very much like the flogging to stop.

This kind of shit is what drives the increased UAC you’re going to see more and more of. If that bothers you, then when you hear fellow devs talking about this kind of idiocy, call them out on it. Get them to stop being assholes.

Because again, if it’s a choice between just regular people not having to become sysadmins and devs just to use their computer and your convenience? I’ll set your convenience on fire, and make s’mores.