Live data from Hacker News

There is no WhatsApp 'backdoor'

whispersystems.org

371–380 of 437 posts

Re: There is no WhatsApp 'backdoor'

#371
post #234

Earlier quoted context omitted.

tptacek, Over the years interacting with you here on HN, I think this basically sums up the worldview that puts you and I at odds: > Open vs. closed-source software is a concern orthogonal to verifiability. Is there a place where you have written at length, defending this assertion? I am open to it. But it does not resonate with my understanding, nor my (substantial, I think) experience in deployments of open- and cl…

Open vs. closed is obviously orthogonal to verifiability. Those who verify software have access to the source, open or not. More parties have the opportunity to be verifiers of open software. However, a given OSS program might not attract skilled verifiers.

> Those who verify software have access to the source, open or not.

That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

Re: There is no WhatsApp 'backdoor'

#372

Earlier quoted context omitted.

> less well-known programs that are much harder to reverse have been productively > It's just not capital-H Hard to do it in closed-source software, so this open vs. closed debate about backdoors is usually a red herring. No, you are oversimplifying the problem a lot. In an Open Source project it is possible to create transparency in the development process by every commit public and allowing 3rd parties to mirror th…

Nope. Professional security people have been using binary diffing tools to solve this problem since the early 2000s.

You keep saying this. Can you back your claims? In particular, the claim that Whatsapp has been extensively reverse-engineered?

Re: There is no WhatsApp 'backdoor'

#373

Earlier quoted context omitted.

The option The Guardian is describing there is something like this: When my partner's key changes: [ ] Show me a notification (y/n) What I was talking about was an option like this: When my partner's key changes: [ ] Wait for my manual confirmation before delivering any messages from my partner that are dated after the key change (y/n) To me it's up for debate whether or not the existence of the first option or the f…

Well, there are two options: notification option and confirmation option. Moxie correctly assumes that confirmation option (require manual confirmation to resend if key changes) should either be enabled for everyone or disabled for everyone, as its state can be determined passively by the server. But it depends on the notification option. His conclusion is that confirmation option should be disabled for everyone beca…

>But it depends on the notification option.

Ahhhh, dependencies. You're right. This is more involved than I originally thought. Here, does the following look like an accurate summary of the situation? (For optional row/cols, "Optional (yes)" with a value of "secure" means "if the feature is optional, it's secure for users who have it enabled.")

                                                          Confirmation:                        
                                     Required    Disabled    Optional (yes)   Optional (no)  
                                   | :------: | :--------: | :------------: | :-----------: |
                    Required       |  secure  |   secure   |     secure     |    insecure   |
                                   | (Signal) |   (Wire)   |                |               |
                                   | :------: | :--------: | :------------: | :-----------: |
     Notification:  Disabled       |  secure  |  insecure  |     secure     |    insecure   |
                                   | :------: | :--------: | :------------: | :-----------: |
                    Optional (yes) |  secure  |   secure   |    insecure    |     secure    |
                                   |          | (WhatsApp) |                |               |
                                   | :------: | :--------: | :------------: | :-----------: |
                    Optional (no)  |  secure  |  insecure  |    insecure    |    insecure   |
                                   |          | (WhatsApp) |                |               |
                                   | :------: | :--------: | :------------: | :-----------: |

Re: There is no WhatsApp 'backdoor'

#374
post #370

Earlier quoted context omitted.

I don't know what "(at best) research level stuff" means. Here's a well-regarded LLVM lifter by a very well-regarded vuln research team that's open source: https://blog.trailofbits.com/2014/08/07/mcsema-is-officially... There are a bunch of other lifters, not all of them to LLVM. Already, with the idea of IR lifting, we're at a point where we're no longer talking about reading assembly but rather a higher-level langu…

> Open vs. closed source is an orthogonal concern to verifiability. The evidence you have presented does not support this conclusion. All you've shown is that it is possible to reverse-engineer object code, but this was never in doubt. It is still an open possibility (indeed it is overwhelmingly probable) that it is a hell of a lot easier to audit code if you have access to the source. All else being equal, more info…

I'm sorry, but once again: this thread began with a different claim. I'm not interested in debating whether it's easier to audit C code or assembly code: I've repeatedly acknowledged that it is.

Re: There is no WhatsApp 'backdoor'

#375
post #371

Earlier quoted context omitted.

Open vs. closed is obviously orthogonal to verifiability. Those who verify software have access to the source, open or not. More parties have the opportunity to be verifiers of open software. However, a given OSS program might not attract skilled verifiers.

> Those who verify software have access to the source, open or not. That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

How do you look at the last 15 years worth of Microsoft Windows OS advisories and conclude that closed source has prevented hats of all colors from discovering vulnerabilities?

Re: There is no WhatsApp 'backdoor'

#376

Earlier quoted context omitted.

Nope. Professional security people have been using binary diffing tools to solve this problem since the early 2000s.

You keep saying this. Can you back your claims? In particular, the claim that Whatsapp has been extensively reverse-engineered?

Are you asking me to "back up" the claim that security researchers use BinDiff tools to reverse out vulnerabilities from vendor patches?

At one of the better-attended Black Hat USA talks last year, a team from Azimuth got up and stage and walked the audience through an IDA reverse of the iOS Secure Enclave firmware. Your argument is that it's somehow harder to reverse a simple iOS application?

Re: There is no WhatsApp 'backdoor'

#377

Earlier quoted context omitted.

I was actually perplexed, after reading about signal, that I couldn't just download an APK. Are play services required for signal? If so, can I even install signal on a cyanogenmod phone? Can you do so by rebuilding it yourself? Does the build match the shipped binary on the play store? To me, Signal does look exactly in the same boat as whatsapp. The fact that WhisperSystems didn't cooperate harder to ship Signal in…

Used to be, called LibreSignal. They ran into legal issues. https://github.com/LibreSignal/LibreSignal There is a bounty for modifying the signal app source to drop play services. https://www.bountysource.com/issues/35722527-create-proper-p...

Also - I don't think the naming issue with LibreSignal was necessarily a legal one per se. Moxie just expressed his opinion that he didn't like that they were using "Signal" in the name. He didn't specifically ask them to rename it. They offered to rename it, to which he replied that he'd appreciate that. (They didn't rename it since they just discontinued it instead).

Re: There is no WhatsApp 'backdoor'

#378
post #371

Earlier quoted context omitted.

> Those who verify software have access to the source, open or not. That's not true. Black hats are essentially verifiers, and they generally do not have access to closed source.

How do you look at the last 15 years worth of Microsoft Windows OS advisories and conclude that closed source has prevented hats of all colors from discovering vulnerabilities?

Why do you keep raising this straw man? It is obviously possible to reverse engineer object code and find vulnerabilities. But it is (equally obviously) easier to examine source code to find vulnerabilities.

Re: There is no WhatsApp 'backdoor'

#379
post #279

Earlier quoted context omitted.

Look if WhatsApp wants to read your messages without you detecting, there's nothing you can really do to prevent it apart from not using WhatsApp. For instance if you're on some list for message interception, they can give you MITMed keys when you first login. Or they can insert some subtle signal that tells the app on your specific phone to ignore key changes and avoid showing notification in some way you would stru…

Doing those sorts of things would leave a trail of evidence, though, since the attacks have to be included in public app store releases. A typical user might not be able to catch trojans in an obfuscated binary, but there are people who can, and the compromised client would be available to anyone who wanted to dig in.

Your point being?

Yes, there would be a trace in the binary. Potentially detectable by maybe one person in a million. Is that supposed to keep WhatsApp from including malicious features? I do not think so.

What happens is: 1. researcher finds a malicious part in WhatsApp binary 2. WhatsApp declares it a bug and fixes with a new binary 3. we are back at square one

Re: There is no WhatsApp 'backdoor'

#380
post #112

Earlier quoted context omitted.

> if the binary doesn't match what whomever gets when they compile, there better be a reason for it. True, but deterministic compiles are stupendously difficult in most cases. Which is improving slowly, but still isn't usually an option.

Debian is up to 92% deterministic builds, so not that hard: https://tests.reproducible-builds.org/debian/reproducible.ht...

Ooh, that is a heck of a lot better than the last time I looked at it. And a very neat link - thanks!
Post reply on HN