4 ms·

If you have the source then you can see what it does. If you only have the binary you have no idea what it does. You can observe what it does today, but what u

by dave2000 11y ago

If you have the source then you can see what it does. 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.

kasey_junk 11y ago
> If you have the source then you can see what it does. 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.
- dave2000 11y ago
  Yeah, it's all old news. I regularly use several different compilers so that's not such the shock you suspect it might be. Also, for your paranoia to be really effective you must also assume the disassemblers must also be in on the act. 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.
  - tptacek 11y ago
    Could you point out some of these "people who do security work"? I should like to meet one someday.
PeCaN 11y ago
> If you have the source then you can see what it does. 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-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...
- dave2000 11y ago
  You compile with various compilers and you decompile them with different decompilers. This is trivial today. 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.
  - tptacek 11y ago
    "Perfectly good PRNG routines"? No, that is not at all true. Serious cryptographic software uses the OS's random number generator. There are not in fact "perfectly good PRNG routines" ready to take off the shelf and plug into crypto software.
  - PeCaN 11y ago

kasey_junk 11y ago

> If you have the source then you can see what it does. 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.

dave2000 11y ago
Yeah, it's all old news. I regularly use several different compilers so that's not such the shock you suspect it might be. Also, for your paranoia to be really effective you must also assume the disassemblers must also be in on the act. 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.
- tptacek 11y ago
  Could you point out some of these "people who do security work"? I should like to meet one someday.

PeCaN 11y ago

> If you have the source then you can see what it does. 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-intel-and-vias-chip-based-crypto-freebsd-developers-say/ http://arstechnica.com/security/2013/12/we-cannot-trust-inte...

dave2000 11y ago
You compile with various compilers and you decompile them with different decompilers. This is trivial today. 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.
- tptacek 11y ago
  "Perfectly good PRNG routines"? No, that is not at all true. Serious cryptographic software uses the OS's random number generator. There are not in fact "perfectly good PRNG routines" ready to take off the shelf and plug into crypto software.
- PeCaN 11y ago