Legitimate question: what is bad about this? I've read all the comments and still don't see a convincing explanation.
Code signing just says you can trust that the software you clicked on came from the actual developer.
It doesn't say anything at all about what the software does. Of course signed software can do whatever it wants. It's not like there's supposed to be some chain of trust that it's only allowed to run further signed code. It's free to run a Python script or shell command or whatever it wants. And installers certainly run scripts.
And as other comments here state, to do anything that requires root privileges, it pops up to ask for your admin password, so it's not getting around that.
I see references to this being a "malware pattern" but no explanation of why or what that means specifically. Zoom is commercial software (not malware) and I don't see how this is a vulnerability (something malware could take advantage of) so I'm not getting it.
Can someone explain what the problem is here? Or is there no problem?
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.
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.
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.
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.
would technically have the same "problem". That's a heck of a lot of apps.
On iOS Apple do insist on a full chain of security, which is why only Apple's own browser app can JIT code. It's an extremely perverse and serious limitation that has no real security justification: consider that Android manages just fine without it.
As far as I can tell, Zoom is currently the target of a witchhunt. People are digging for dirt and blowing stuff well out of proportion.
There are a lot of people blowing things out of proportion who don't know what they're talking about. However these things are newsworthy and probably worth Zoom fixing. (I think to a certain extent if I say something like "It's dumb that Zoom doesn't have real e2e encryption and they should fix it." That sounds harsh and I mean it. That said I'm still going to use Zoom unless something with equivalent UX and e2e encryption comes along.
(Someday there will be a solid cross-platform native p2p video client with e2e encryption.)
FaceTime? It probably doesn't work at conference scale but it is E2E.
> We designed iMessage and FaceTime to use end-to-end encryption, so there’s no way for Apple to decrypt the content of your conversations when they are in transit between devices.
But that's a total lie, isn't it? They can just send your iPhone a public key owned by Apple. Or they can put a backdoor in the app and get you to install an upgrade.
E2E is snake oil at the moment. Nobody has developed a reasonable UX to let people exchange keys, and closed source clients that can be centrally updated render any such encryption pointless. It could be disabled at a moment's notice and you'd never know. I don't blame Zoom for not investing in it.
i was about to write the same comment. id bet the percentage of HN readers running 100% signed code is damn close to 0.
the zoom witchhunt is really something. zoom may or may not be a witch (im no China apologist, i yell at all my friends for using tiktok), but if we get the answer right it will be based on luck and emotion, not logic and reason.
> zoom may or may not be a witch (im no China apologist
Zoom is an American company, headquartered in the US, employing mostly Americans, subject to US law, etc. Its CEO is an immigrant, but that's true of half the American tech companies out there, including Google and Microsoft.
EDIT: I'm white, but my wife is Asian-American and has told me more than once how white people often treat Asian-Americans as if they're not real Americans. I'd never witnessed that myself, but I guess the above comment is the kind of sentiment she's talking about. Zoom may or may not be a scummy company, but its founder's birthplace is immaterial. He's a US citizen, and deserves the same treatment we give to maybe-scummy white American CEOs like Mark Zuckerberg.
"“Our product development team is largely based in China, where personnel costs are less expensive than in many other jurisdictions,” Zoom wrote in a regulatory filing."
The concerns about TikTok are that it's potentially Chinese government spyware because TikTok is owned by a mainland Chinese company which has legal obligations to the Chinese government.
Zoom is a US company that is not answerable to the Chinese government. Like many companies, Zoom has chosen to outsource some of its operations, and those overseas offices create various infosec risks. And given that Zoom infosec seems to be a total clown show, those infosec risks are probably more serious at Zoom. But that would be equally true of any other American company that is really lax about security and too cheap to employ American developers.
Not entirely true. While Zoom as a company is not answerable to the Chinese government, the developers are.
Given that we have such horrible laws even in the "more democratic" parts of the world, such as Australia [1], it is not unthinkable that the Chinese government may ask a Chinese developer to install a backdoor to a foreign based product they are working on:
> The Electronic Frontier Foundation has said police could order individual IT developers to create technical functions without their company's knowledge.
except its not an office, its the majority of their dev team operating inside one of the top 3 unsafest, most anti-american (with respect to cybersecurity) countries in the world.
> Zoom is a US company that is not answerable to the Chinese government.
If that was true, then events like the Huawei USA "Tappy" [1] incident wouldn't have occurred. In any case, I'm not trying to take a stance here but merely wanted to correct your statement that they had more engineers in the US than in China.
Their employees are mostly American, as I originally stated. Their engineers are not.
Huawei USA is almost certainly majority controlled by Huawei China, whereas Zoom's Chinese subsidiary is almost certainly majority controlled by the US parent company. Hence, Huawei is a Chinese company for practical purposes (the people calling the shots will go to jail if they don't do what the CCP wants) and Zoom is an American company (the people calling the shots go to jail if they break American law, and are mostly out of reach of the CCP).
Did you even have signed apps (typically) installed in Leopard?
Anyway, it depends on the standard of proof. But for the parent comment, it's fairly easy to get most reasonable people to agree that it's false. As a reminder, the claim is about:
> the number of Mac users running 100% signed code
Obviously OP meant outside of sandboxed environment.
There might be exploit out there that exit the sandbox, but they are unintended. But here zoom is intentionaly widening an exploit by being reckless. So thanks to zoom we might now expect even more drastic sandboxing in next MacOS release.
I disagree, not only is it not obvious - it's fairly obvious that he didn't mean that.
> the number of Mac users running 100% signed code is well over 50%
Would you say he meant "number of users running exclusively sandboxed code"? Or do you claim he means "number of users running 100% signed code outside the sandbox"? The only claim that would even make sense is "more than 50% of Mac users run exclusively sandboxed code". And it can't mean "app sandbox", but any kind of sandbox? Like, do java programs qualify? Is the JVM malware? If you install a signed app that requires the JRE, do you also install something that could run unsigned code?
Code signing just says you can trust that the software you clicked on came from the actual developer.
It doesn't say anything at all about what the software does. Of course signed software can do whatever it wants. It's not like there's supposed to be some chain of trust that it's only allowed to run further signed code. It's free to run a Python script or shell command or whatever it wants. And installers certainly run scripts.
And as other comments here state, to do anything that requires root privileges, it pops up to ask for your admin password, so it's not getting around that.
I see references to this being a "malware pattern" but no explanation of why or what that means specifically. Zoom is commercial software (not malware) and I don't see how this is a vulnerability (something malware could take advantage of) so I'm not getting it.
Can someone explain what the problem is here? Or is there no problem?