So yeah, Whatsapp has made a probably positive move, but it is still largely unsafe.
Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes. Painting open source as being a magical wand that wishes away all our security troubles is completely out of order.
Edit: I'll go further. It's become dismayingly apparent that very little systematic code review of open source software in order to secure it is actually taking place. It now seems quite possible that the most thorough investigations of software vulnerability, via code analysis or any other techniques, are carried out by those wishing to exploit them. They are well funded and highly motivated. Looked at in that light, the balance may well tip towards open source actually increasing the likelihood of software vulnerabilities being exploited maliciously.
The open source community has a long way to go if it's going to clearly demonstrate that it's model is advantageous, and complacent pronouncements of it's assumed superiority like this aren't going to achieve that.
The code being publicly available does not guarantee security but makes insecurity easier to find which on balance indirectly increases security.
The actual point is not security, but trust and certainty. Being Open Source does not change whether some messaging app is secure or not. It changes our knowledge about the code. It also makes me have a little bit more trust in some company for revealing their stuff.
Even if WhatsApp open-sources the clients, there is still the problem of US jurisdiction. NSA can force them to silently including a backdoor or send everything to NSA-servers.
Trust is a difficult thing.
What you definitely don't need is permission to redistribute, modify, etc. the software. Those are important for user freedom, but for the goal of verifying that a particular app on a walled-garden app store does what it claims to do, those don't help you. You just need access to source code.
What you do need, whether or not you have source, is an understanding of what the software does. Sure, you can probably do this by disassembling the software. But if you can disassemble the software and understand it, there is nothing more that having the actual source would tell you. If the company is expecting that people will disassemble it to verify it, they might as well release source.
What you also need, given either source or a binary, is assurance that everyone else is running the same binary as you have. Given source, that probably requires reproducible builds and a documented and reasonable build chain. Given a binary, that requires some distribution mechanism that ensures that everyone in fact gets the same binary.
No - the code could be "open source" but unreadable. But if it's not open-source there's definitely nothing we can do.
> Heartbleed and Shellshock, the two most significant vulnerabilities found in heavily used open source software, were found by vulnerability testing and not code inspection. So while being open source is a nice-to-have attribute for a piece of software, that's as far as it goes
a) afl-fuzz and the like require access to the source code.
b) Those were the vulnerabilities that made it into production. They tell you nothing about what proportion of potential vulnerabilities were stopped by it being open source.
I think this doesn't fundamentally change my point though. ali-fuzz was used to find shellshock, but that vulnerability had been in bash for decades. If it had ben found and closed within months of being introduced I'd be cheering the advantages of open source with the best of them, but that's decades during which a bad actor could theoretically have found and exploited that vulnerability with impunity using code analysis. That's exactly what I mean by the balance of advantages versus disadvantages of open source being tipped the wrong way right now.
I'm not enemy of open source, far from it, I'm just arguing for an open and honest assessment of the situation. If open source is really going to be a genuine security advantage, there's an awful lot of work to be done to make it so. It's not going to happen spontaneously.
I don't think you've shown anything about relative vulnerability rates. I agree that there are massive problems with even major open-source projects, the general state of software security is terrible, and we have a lot of work to do on that front (starting with moving to memory-safe languages post-haste). But none of those things contradicts that open-source software is much more secure than closed-source software.
In reality, software security is a function of the amount of expert attention that has been paid to a given piece of software. Popular open source software attracts a certain, stochastic, significant amount of attention, but money buys a more reliable amount of attention. There is insecure open source and secure open source, insecure closed source and secure closed source. Open source is a red herring.
There's a reason why, for instance, Firefox had Bleichenbacher's E=3 vulnerability, while IE didn't.
This is very much not true. Understanding what any executable does is possible without the source code. In fact, if you are looking at the binary, you know exactly what you are dealing with, and don't have the doubt about what the build chain actually does with the source.
potential vulnerabilities were stopped by it being open source.
This presumably comes from "many eyes make all bugs shallow". But operationally this is not true, because there isn't really, except for rare circumstances, any useful review.
How is it less safe than not having the source, though? Absent the source, how can you trust that the once trustworthy, if secret, code hasn't been nobbled via hackers, a court order etc.
The model of security through obscurity is what's broken, and that's what we've got here. You have to trust Facebook today, and forever and trust anyone else with the technical or legal power to silently violate its security; something that's much harder if the code is available for analysis.
In this case, if you're ideologically attached to open source, you're in luck: the cryptographic components WhatsApp uses are open source, and there's another good messenger that uses them: Signal, by Open Whisper Systems.
You are not in fact stuck with Facebook's "say-so" about what WhatsApp is doing. Obviously, if you have the executable binary, you can straightforwardly validate its functionality with a disassembler/decompiler. There are thousands of people that do this professionally.
There might be some other reason why it's important that WhatsApp's code be published, but it can't possibly be this one.
Personally if I was the NSA or GCHQ I think it would be a wicked smart plan to release this and have it be actually secure, have it audited, gain trust, let people use it for a while then after a while release an update that shoved all the messages in memory to a server somewhere once people let their guard down. Implausible yes, but that's the issue with trust. And I'm not sure releasing the clean source would really help this. The only thing would be to hold up on updating the app until a trusted party had audited the updated binary. More paranoia: Also would have to audit the specific binary for every country with wierd laws (e.g. UK's RIPA) appstore to make sure we didn't get a nice local flavour of poison.
I was wrong about heartbleed, it was found through a source code analysis technique called fuzzing - decades after the vulnerability was introduced. That's decades during which source code analysis could have been used by bad actors to find the same vulnerability and exploit it.
Opening the code doesn't by itself eliminate the vulnerabilities. What it does do is fire the starting pistol on a race between black hats and white hats to find and either exploit or close the vulnerabilities. It's very much a two edged sword. So what we need is confidence that the white hats are winning that race.
The race is more dependent on motivation than whether the code is open or closed. Often, blackhats are financially motivated (whether they themselves monetize the vulnerabilities directly - or they are hired-by/paid-for a 3rd party) - they factor in their return on investment (ROI). Open source merely makes their job easier but given enough motivation, they can and will find vulnerabilities in binaries, remote services, etc almost as easily.
One problem is that many people believe in "many eyes makes all bugs shallow". Numerous examples prove that assumption false. Is it because there is more financial interest in closed systems? ...or is it because in open systems people automatically assume that because it's open that someone else must have vetted it? (e.g. "if I'm interested in it, and thousands/millions are too, then it's highly likely some expert better than me already looked at")
Some in the open source community flout the "many eyes makes all bugs shallow" argument, but in the free software community we do not assert this. Part of security is transparency, and this means being able to read the source code, freedom 1. Free software is a prerequisite for secure software that a user can trust.
More here:
If you are opening up for incivility, I doubt there is an end what people will start calling each other. Do you really want to go down that road?
Obviously, a WhatsApp backdoor would not in fact take that form.
Bash was released in 1989 and initially development started some time before that.
OpenSSL project was founded in 1998.
Windows XP was initial developed in the late 1990s, released 2001.
Macromedia Flash 1.0 was released 1996 and initially developed a couple years before.
So should we only count software vulnerabilities that was created after 2010? 2016? What proof would satisfy you?
Or are you confused by your own argument that software written in the mid-to-late 1990s tend to be insecure software, and thus we should disregard that some software has been more exploited historically than others?
But if the code is not open source, we _cannot_ verify it's security?
Ability is already good. Not enough but necessary.
https://news.ycombinator.com/item?id=11432047
In short, "sources do not guarantee anything, and it's better to inspect the binary directly".
Which makes sense, we've known for a very long time that you can't trust the source, so you must verify the binary one way or the other.
Or you could observe what the original binary actually does, which you need to do anyway.
If you only have the binary you have no idea what it does. You can observe what it does today, but what use is that if tomorrow it receives a short message from Facebook which tells it to email back the encrypted, compressed copy of your messages it's been quietly keeping for the last few hours/days/weeks?
The argument "what about this or that open source project with bugs in it" is silly. It's an argument for more scrutiny of code, not blindly trusting in third party code where you have no idea if they can be trusted today, or in the future, or can be compelled to spy on you, or introduce weaknesses deliberately into their products. Open source mitigates against several of these risks.
That is literally false. We have known from the 70s that you cannot know what an application will do from the source. I can't believe I'm actually having to reference "Reflections on Trusting Trust" but it is the entire point of one of the most seminal talks in our industry.
To defeat that style of attack you literally need 2 different compilers, I didn't pick that out of a hat, its also from the literature.
> If you only have the binary you have no idea what it does. You can observe what it does today, but what use is that if tomorrow it receives a short message from Facebook
Figuring out what a binary does without source is a very common task in our industry. I'm told there are people who do it for fun, and I know people that do it for money.
Regardless of whether you have the source or not, you have to verify the binaries behavior, both because of intentional trusting/trust attacks and for flaws that are non-obvious from the source.
I'm sure the source is helpful, and the source with repeatable builds is even better but its not a requirement nor does it seem to be a very high priority for the people that do this sort of work professionally.
>"what about this or that open source project with bugs in it"
I am certainly not making that argument.
You need the source to have even a crack at being sure there's no foul play. Trusting the current behaviour of an app now is no guarantee. Anyone could write an app which, when it receives a certain message at a certain time changes subtly its behaviour. If you had the source this wouldn't be possible (ok, it would be possible if someone's got at the app and all major compilers and disassemblers going back years and want to blow that little secret on this one exploit); you'd have a chance of seeing the logic.
If you don't have the source then you're no better off because you have all those risks plus you have no idea whether or not someone has good intentions but a poor testing regime, or a bad actor, or any number of other problems.
People who do security work successfully seem to be unanimous that you don't do your own security, and that you use open source solutions so you can see that people are doing what they say you are doing. And this is done in the name of reducing risk, by reducing the number of people you have to trust.
What if it exploits a compiler bug to do something different than it looks? What if the compiler recognizes the code and instruments it with its backdoor? Sure, GCC probably doesn't, but what if the code was meant for Windows and only builds under MSCV which you can't audit? What if the code exploits an undocumented “feature” in Intel x86 processors? What if it uses a backdoor in Intel's randomness hardware? Modern Intel processors have many undocumented features and essentially can do whatever the hell they want with your code. The NSA almost certainly has a backdoor in Intel's RDRAND[1]. x86(_64) is impossible to trust; even VIA CPUs may be compromised (though they lack the “management engine” of Intel and AMD—if I were to 100% audit a crypto-related program that only runs on x86, I would use a VIA system and intercept any instructions that use the hardware RNG).
Point is, open source makes some things vastly easier, but the point is you _need_ to audit the binary anyway. That's the _only_ way to trust it. You _cannot_ trust the source code. You cannot even trust a machine other than POWER, RISC-V, or SuperH/JCore.
If you're not going to be paranoid as all hell, auditing crypto is pointless.
1. http://arstechnica.com/security/2013/12/we-cannot-trust-inte...
Randomness hardware? There are already perfectly good PRNG routines available as used by currently available strong encryption.
I understand the criticisms of just relying on the fact that something is open source but the alternative - closed source - has exactly 100% of those problems, plus a whole other lot of new ones too.
Yeah. How do you seed those with a good source of entropy? That's what RDRAND etc are for.
It's not unsafe, you just don't know if it's safe or not. That doesn't make it unsafe.
Even if the code were open source and there were some guarantee that WhatsApp was using that exact code during compilation, you still would not know if it's safe. Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not.
There is always going to be an unknown here, and open source does not reduce that much risk. In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code. Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that.
All we are really left with then is trust.
Speak for yourself
> Just like most other people, you are relying on people experienced with such things to confirm that they are doing things in a "safe" way. Thus for all practical matters, it really doesn't matter if it's open source or not.
If you rely on the experts then it still matters to you whether being open-source means more or better experts.
> In fact, it's probably better to look at how WhatsApp, the software, behaves (i.e. what it does on the wire) rather than the code.
It is provably impossible to tell whether the RNG has been backdoored that way.
> Sure there could be backdoors, but that is the risk you take when you use any pre-compiled software -- open source doesn't change that.
Huh? So you require reproducible builds and/or build from source yourself. You absolutely don't trust that some random binary is what it claims to be.
At what point does this all become totally impractical? Should you also manufacture your own chips as well to make sure there are no backdoors at the hardware level? How about for people who have no time for any of this (99.99999999% of the world)?
At some point, you need to trust somebody in this chain of dependencies.
People who are beating their drums about open source are in essence saying: trust no one. But in the real world, that is not realistic.
You should ensure that your supply deal allows you to audit the manufacturing, yes. Maybe you don't actually have the time or money to do so, but if they don't offer that capability that's a giant red flag.
> At some point, you need to trust somebody in this chain of dependencies.
You never trust any single party unconditionally. I mean sure, even if you get an audit done, your audit agency could be crooked - a sufficiently large conspiracy can defeat anything a single person can do by themselves. But you don't want to put yourself in the position where one rogue company - or even one rogue employee at that company - could entirely compromise your security. If that level of security is good enough, why even bother using encryption at all?
Even if the crypto was good, the cognitive load of having to decide whether you want a chat to be secret or not makes it a bad choice IMO, especially if it comes with a downside.
> All applications must be considered unsafe unless we can review the code.
Let's face it. I like to give the liberty to people who prefer to keep their code secret and their responsibility to hire people to do proper security auditing. Curious whitehats are welcome to attack systems which have bounty program. While obfuscation is never a good idea in security, the paywall between Facebook and the public keeps large exploits away. Attacks came directly from behavior testing require some cleverness and dedication (of course there are those really dumb XSS everywhere). So in this case, obfuscation by hiding the source code is one way. However, you can argue that someone could have lost work laptop and steal the source code (let just assume some startup whose git repo is clonable entirely onto the laptop).