But how could it be modified? What is the threat model? An evil network? TLS solves that. Evil code on the local machine? You are boned anyway and probably lose to TOCTOU problems when validating the signature on the script.

redistribute the modified zoom installer from your own domain. Send meeting invites with a link to the modified zoom installer.

You get the zoom signed package installing your unsigned code.

And somehow break the binary's signature?

But the truth is you don't really need to do that. If people are coming to your own domain you can ship them whatever you want. I'd wager that well below 1/1,000,000 users actually verify signatures on binaries. For the huge majority of users, there is little you can do to prevent this.

But if you modify it, it's no longer signed?

apparently the issue is that you could modify the script, keeping the script-launching binary unchanged and signed?

did not try/verify though

How are you planning on modifying the script?

The network can't do it if it is downloaded over TLS. A malicious host can already ship evil scripts. Malware on the local machine can already do worse that edit a script.

The installer is code-signed, and requests root privileges, right?

>Malware on the local machine can already do worse that edit a script.

Malware on the local machine may not have root rights. You're basically arguing that privilege escalation isnt a real threat.

I agree that a dumb signature validation will have TOCTOU problems but the solution is better validation, not to abandon signatures.

I'll ask again.

What is the threat model?

To me, all this looks like people knowing that signing is somehow good and demanding it in a context where it isn't clear that it makes sense. And given that the top post in this thread is about skeevy domains, how the heck would signing scripts achieve anything? Even the reposted tweet says "don't think you could weaponize".

The threat model is a malicious entity has limited access and can swap out the intended script for a malicious one, and have it run in a root context.

This is equivalent to not having signatures on your repository packages and saying "no biggie, we rely on transport encryption". Might work in most cases, but there's a reason good security uses layers. A failure at any point-- TLS downgrade attack, repo compromise, proxy compromise, DNS poisoning-- can result in your preflight script executing malicious code.

Requiring code signing with a pinned cert would solve this issue, but would be terribly out of character for the company that brought us a hidden local REST API to bypass OSX security prompts.

But isn't this an issue in the OS security system? Zoom is only using a loophole, just like any malware would.

Same with the recent story on UNC links in Zoom chat. That's an issue in Windows. Why is windows sending your password out on the internet willy nilly? In this climate, 2020, Microsoft should know better.

One could argue that legitimate software acting like malware is an issue in and of itself.