Of note, Apple has had its own malware detection and removal system in place since the Mountain Lion - Snow Leopard timeframe. Since this article speaks to removal, it's sounding like the Zoom local server may have had its signature added to that system.
Beyond the unsolicited reinstallation (== malware) behavior other commenters rightly mentioned, the entire existence of the vulnerable server was a hack to work around a Safari security feature. Zoom wanted to eliminate an extra user click, required by Safari to confirm that it was OK to invoke a local application based on the public zoom link. This server was an implementation of that security "workaround".
That makes this server at least doubly malware. And "vulnerability" understates the case: a negligent implementation that utterly disregarded any security concerns should be considered beyond the pale. That times 1000 for a major software vendor like Zoom.
The server was intentionally left behind, and running, by the "uninstaller". The server would respond to requests by reinstalling the intentionally uninstalled software.
That's malware.
The server itself was deliberately added to work around a Safari security feature, that was designed specifically to prevent what they wanted: allowing arbitrary web content to open an app without user consent. They literally added an always on, persistent server, to avoid a security dialog
> The server was intentionally left behind, and running, by the "uninstaller
FWIW, I don’t think there was a uninstaller? What I’ve seen people describe is that dragging the .App file to the trash wouldn’t remove the server, since it was installed in a different folder.
There was no uninstaller until the Zoom update this week added an uninstall option to the menu.
MacOS users expect an app that does not come bundled with an uninstaller to be "uninstalled" by dragging the .app bundle to the trash. This generally leaves behind metadata, but that is not a big deal as it is just data - not code.
Leaving behind code that continues to execute after the user has removed the application without an option to uninstall it is obviously something that never should have shipped in the first place from a customer trust perspective.
The server was deliberately left running: if it was unintentional it would just error out if Zoom had been removed. Instead it downloaded and installed the client again. That’s fairly clearly designed to override the user’s attempt to remove the software, and is exactly the kind of thing malware does.
There is a real problem many (often primarily windows) apps have this bizarre desire to “install” content randomly scattershot across the OS. There is no reason to do this on Mac OS. OS X happily supports multiple binaries and services per bundle.
If you write an app that needs an uninstaller on OS X, and you aren’t needing to install some kind of driver, your app is doing things it should not be doing, and does not even need to do.
It is perfectly supported to leave daemons in your app’s bundle. There was no requirement to install the executable to a different directory. They appear to have done it to ensure the web server could silently reinstall the app after the user deleted it.
Yes, as is, dragging apps to the trash cannot do that.
Apple should probably implement an API that allows developers to tell the OS what other stuff should be removed if the app is dragged to the trash.
To prevent devs from removing other people's stuff, you could require that the subcomponents need to be cryptographically signed with the same key as the main app bundle.
edit: or, even simpler solution (potentially) - have a fairly basic API via which devs can install subprograms elsewhere on the system. When you use this API to install something, it adds the thing installed to an OS-level registry. When the user drags the app to the trash, the OS checks the registry and removes anything that was added by the application.
The real solution is to not install anything outside of your app bundle in the first place. In this case, instead of sticking a plist in ~/Library/LaunchAgents, you can use an API to add a login item, pointing to a helper .app inside the main app bundle:
Then the system will automatically disable the login item if the app is removed.
Edit: It seems like Zoom was using a login item, but using the "shared file list" API instead of the newer (but still dating back to 10.6) SMLoginItemSetEnabled.
An alternative is to just make your daemon check for itself whether the main app has been removed, and delete itself if so.
No, on OS X there is literally no reason to move anything from out of your application bundle. Copying the server out of the application bundle had one effect: it makes removing the app not remove the server.
There are apis to register for launch, there are launch service plists, etc which all correctly, and by default handle the user deleting your app bundle.
There are already “cryptographic mechanisms to detect modification of your app”, it’s the platform code signing mechanism, and Xcode will produced signed binaries by default.
Finally, your post comes across as saying that you believe leaving the server was unintentional due to lack of APIs (ignoring that removing an application is a sign that the user doesn’t want your app to run any code). Their “unintentionally” persistent server explicitly check for the app being removed, and if it had been, would redownload it and install it without user consent.
I think your edit is describing a package manager :D Or the Mac App Store... (But yes, it would be good if this feature were available for apps that can’t come through the App Store)
There was a reference to an uninstaller in one post, but also it is expected the uninstalling an app on macOS is simply a matter of deleting the app package.
But again, this was deliberately subverted by the client copying the server out of the app package and into a hidden folder in the user's home directory. Again, this is an intentional choice mimicking malware: the only reason to move the server binary is to break the standard app removal process.
But I maintain that the smoking gun for this being intentional is that the server will download and reinstall the client software, which only makes sense if you expect it to run when the user has uninstalled/removed your software.
Yes because even if you purposely uninstalled the application it would reinstall if you went to a link even by accident without really notifying you that it did so.
That's Apple's closed garden, even when they allow you to sideload application, they still have the ultimate decision. Of course it's not malware, but probably enough users have vulnerable software which could be remotely exploited, that they decided to blacklist it.
Malware is a software written to harm user. Their purpose was not to harm user, they wanted to make their service more convenient for users. Bugs are bugs, every product have bugs and many products have security bugs. That does not make them malware.
Intent doesn’t matter only results. The result is that unless you like for random websites to be able to activate your camera without your permission, it did harm users. It wasn’t a “bug”. They purposefully hacked around a security feature. Do you really think it was a “bug” that it reinstalled itself?
Then you should call Chrome a malware because there were vulnerabilities with remote code execution (and there will be similar vulnerabilities), so every website could install anything. But that is absurd.
> The result is that unless you like for random websites to be able to activate your camera without your permission, it did harm users.
First of all, you need a hard data that this vulnerability was exploited in the wild. Otherwise it did not harm users, it only opened a way for malicious websites to harm users. And, again, every vulnerability could be counted as a malware by that definition which makes malware term meaningless.
> Do you really think it was a “bug” that it reinstalled itself?
It is intended behaviour. And I don't see anything drastically bad with it. If you're opening their website with corresponding link, you want to use that service. In order to use that service, you have to run additional software and they are making it easier for you to run it. Only a few years ago every browser supported Java Applets and with Java Applets every website could run arbitrary code on your machine. And that feature was actually used a lot. Does it make all services which used that feature to overcome browser weaknesses malware? I don't think so.
They probably should have communicated better about that aspect and provide proper uninstaller software for security-concerned users. And not making those vulnerabilities in the first place, of course. But world is not perfect.
> So would it also be okay for a credit bureau to post all of your information to a website? Would that be okay until it was “exploited in the wild”?
I'm not saying that it's okay. I'm just saying that it's an overreaction to call their software malware.
> Are you really saying it’s okay to run knowingly insecure software until there are reports of it being exploited?
Yes, it's okay. When Windows security team receives some vulerability report, they do not shut down all Windows systems in the world until the bug is fixed. Those systems continue to work insecurely until they got update.
> Java applets ran in a sandbox.
Signed Java applets do not run in a sandbox and have full access to the computer. That's why they were widely used for things that JavaScript did not have access to, e.g. using USB secure tokens for website authentication.
There is tons of malware that doesn't harm the user. Take crypto mining for example: it raises the temperature and the electricity bill, but those things aren't per se harmful (albeit financially). Or how about a botnet client that harms some other entity but not the user who owns the machine it's on? Or adware? The list goes on and on... calling this nefarious behavior "harm" is a huge stretch but calling it "malware" is not.
> A program that surreptitiously reinstalls software when you uninstall it is by definition malware.
Not quite. Malware is short for "malicious software" and malice has a specific legal definition: the intent to harm. By your standard, removing a Mac system daemon only to have it re-installed by a software update would classify the entire OS as "malware" - which is an unfair, emotionally-driven characterization.
Windows Defender wouldn't do it silently though, it would make sure you know what happened and get more information about it - even reverse its actions.
Yeah you’re just looking at the version of the xprotect binary, not the malware signature data files, which don’t live in the bundle and get updated more regularly.
They also ship silently via system_installd, you’re not going to see anything in the software update GUI
The signature files also live inside the XProtect.app bundle, unless in true Apple fashion they’ve got other stuff that’s lurking elsewhere in /System that I can’t locate.
