Are they somehow obfuscating their binaries, or are they simply LLVM output? Is it your belief that straightforward compiler output is somehow infeasible to verify?
"Reverse engineering a specific version [every version?] of a private binary is a reasonable burden of proof for users to undertake in order to feel confident in the encryption used by their comms"
What? I usually agree with your takes but this seems out there (or did I misread/mischaracterize it)
You would still have to audit every the code of every released version right?
Reverse engineering is obviously more difficult but someone with the right skills and tools would find it a straightforward task.
Also - unless you are somehow also inspecting their CI/CD toolchain, there's no guarantee that the source being inspected matches the binaries being released - so you would need to reverse the binaries anyway.
It’s already too hard to find security bugs in clean source code. Analyzing a binary can confirm the existence of encryption and the overall crypto scheme, but not the absence of backdoors.
Help me understand how the exact opposite thing isn't true? The binary is the true record of what the platform is actually going to execute, unlike the source code.
What he means is that it's not practically feasible. Experts and a few talented crackers have the expertise to go through a binary with tools like IDA Pro and analyse it, but the process takes a lot of man-hours and is much harder than auditing source code. So yes, if there is a problem with Zoom the NSA and other state-run agencies will find and exploit it, but ordinary security professionals might not have the combination of manpower and expertise needed.
Since it's used so much now, I still hope that somebody reverse-engineers some of the clients. In contrast to auditing open source code, this might also pose legal problems, though.
If the build is reproducible, you can analyze the source, compile it and verify they're distributing the correct binary. If the build isn't reproducible for some reason, you can still do this on some subset of the code.
Now, of course, the binary is what gets executed, so it is the ground truth.
Because the analysis needs to be done by a human mind, and it's 10x more difficult to analyse a binary, even with some tools. And it is already hard to analyze even clean source code, because there can be hidden backdoors, they are not always all called "function SendDataToFBIForTracking(data)".
I should have qualified my statement better. There aren’t many people in the world who can accurately audit a complex application. Evidence of the above fact is that there are approximately zero complex applications without a history of security issues, and there have even been successful attempts to maliciously add exploitable bugs in open source projects.
Among these people only a small minority is able to perform a similar audit on compiled code, and only at a much lower pace.
So I agree that it is possible to check a binary, but it is not feasible in a reasonable way.
PS. You are a well known (maybe even famous in the community) software security expert. Your perception of the availability and competence of good experts may be skewed by the fact that you probably know most of the good ones
He can maybe do it, and a few dozen of other people. There aren’t simply enough good experts to do it on any significant portion of popular software products.
Their terms of service disallow reverse-engineering or even disassembling the binaries: https://zoom.us/terms
> You agree that You will not use, and will not permit any End User to use, the Services to: (i) modify, disassemble, decompile, prepare derivative works of, reverse engineer or otherwise attempt to gain access to the source code of the Services
That's nice and all, but unless you can install their software by compiling the source yourself you have no chance of verifying that the implementation is actually correct. Even with the source available that's an extremely difficult task.
