So the local server is not a regular price of software with a vulnerability, it is now considered malware?
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.
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
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.
If I drag photoshop to my trash instead of using Adobe’s uninstaller, I’m pretty sure that leaves Creative Cloud junk running on my machine.
Now, zoom did mess up by not having a proper uninstaller shipped with their app, I think a lot of other Mac apps do fail at this too though.
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.
https://developer.apple.com/library/archive/documentation/Ma...
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.
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.
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.
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.
So yes, malware.
A piece of software that lets any website activate your camera without your permission is a security vulnerability.
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”?
Are you really saying it’s okay to run knowingly insecure software until there are reports of it being exploited?
Only a few years ago every browser supported Java Applets and with Java Applets every website could run arbitrary code on your machine.
Java applets ran in a sandbox.
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.
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.