6 ms·

> not in the source code, where they would be more easily found. Why do you say that? Compiling the source with the same compiler and flags, plus diffing the

by pbsd 13y ago

> not in the source code, where they would be more easily found. Why do you say that? Compiling the source with the same compiler and flags, plus diffing the binaries would quickly show where the differences lie, and if they're hostile. Any half-decent reverse engineer could do this. That would stand out more than if the source itself was backdoored in a non-glaring way. Open source has taught us that nobody ever reads the source.

lambada 13y ago
That would require a deterministic/reproducible build process. Such things tend to need the same host-OS, library versions, dependency versions etc that AFAIK Truecrypt haven't got documented anywhere. See the efforts of Tor Project, Debian et al to start doing reproducible builds - It's not easy. And this is without things inherently producing non-deterministic builds - embedding timestamps is quite common for example. https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds
NateLawson 13y ago
Yes, that is correct. I founded SourceDNA.com as a way of automating this kind of analysis. We match components found in binaries in order to identify unlicensed use of third-party code, as well as security patches. Tools like bindiff have been around for years and take advantage of the fact that compilers don't randomize code generation. Instead, the callgraph and control-flow graphs largely reflect the structure of the original source code. Once you have leverage by exact-matching the parts of the binary that are nearly identical, you can build up and down the tree of nodes to find those that have more changes. Crypto backdoors can be unbelievably subtle though. A single branch condition, a bit that is flipped, etc. can all lead to catastrophic failures. For example, a compiler optimization for dead code elimination led to some zeroization of key material being skipped. This kind of thing is extremely difficult to find and requires a careful understanding of the underlying code. I agree with you that most differences can be found, but understanding the ramifications of those differences requires extremely careful analysis. A crypto flaw does not stand out from a mis-optimization.
- foobarbazqux 13y ago
  > a compiler optimization for dead code elimination led to some zeroization of key material being skipped. That sounds like a pretty broken compiler, do you have a minimal example?
  - Hello71 13y ago
    This is likely a reference to the Debian OpenSSL fiasco. http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571
    - foobarbazqux 13y ago
      Oh I see. That is a lot of fiasco. I guess I'm mostly curious about a minimal example of useful code that a dead code eliminator will incorrectly optimize.
      - epsylon 13y ago
        In the debian fiasco it's mostly a case of "manual code elimination" [1]. However there are plenty of examples of compilers aggressively removing code that causes undefined behaviour. Basically, when the compiler encounters UB, it can do whatever it wants to code that triggers the UB, which means possibly removing it. Compilers exploit this fact a lot because UBs happen a lot in "normal code". See here [2] for examples and explanations; I also can't help but mention John Regehr's blog [3] if you're interested in compilers, security, testing, safety. [1] http://research.swtch.com/openssl http://research.swtch.com/openssl [2] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... [3] http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213 is a great article for example.
    - tedunangst 13y ago
      That doesn't seem like a good fit. It wasn't a compiler problem, it wasn't dead code, and the problem wasn't skipping zeroing, it was too much zeroing!
unuthu 13y ago
Umm, I think the person above is actually correct, though I'm by no means an expert. Otherwise, why would it take such a huge effort to achieve a deterministic build process as tor seems to have recently done?

by pbsd 13y ago

lambada 13y ago

That would require a deterministic/reproducible build process. Such things tend to need the same host-OS, library versions, dependency versions etc that AFAIK Truecrypt haven't got documented anywhere. See the efforts of Tor Project, Debian et al to start doing reproducible builds - It's not easy. And this is without things inherently producing non-deterministic builds - embedding timestamps is quite common for example. https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds

NateLawson 13y ago

Yes, that is correct. I founded SourceDNA.com as a way of automating this kind of analysis. We match components found in binaries in order to identify unlicensed use of third-party code, as well as security patches. Tools like bindiff have been around for years and take advantage of the fact that compilers don't randomize code generation. Instead, the callgraph and control-flow graphs largely reflect the structure of the original source code. Once you have leverage by exact-matching the parts of the binary that are nearly identical, you can build up and down the tree of nodes to find those that have more changes. Crypto backdoors can be unbelievably subtle though. A single branch condition, a bit that is flipped, etc. can all lead to catastrophic failures. For example, a compiler optimization for dead code elimination led to some zeroization of key material being skipped. This kind of thing is extremely difficult to find and requires a careful understanding of the underlying code. I agree with you that most differences can be found, but understanding the ramifications of those differences requires extremely careful analysis. A crypto flaw does not stand out from a mis-optimization.

foobarbazqux 13y ago
> a compiler optimization for dead code elimination led to some zeroization of key material being skipped. That sounds like a pretty broken compiler, do you have a minimal example?
- Hello71 13y ago
  This is likely a reference to the Debian OpenSSL fiasco. http://www.debian.org/security/2008/dsa-1571 http://www.debian.org/security/2008/dsa-1571
  - foobarbazqux 13y ago
    Oh I see. That is a lot of fiasco. I guess I'm mostly curious about a minimal example of useful code that a dead code eliminator will incorrectly optimize.
    - epsylon 13y ago
      In the debian fiasco it's mostly a case of "manual code elimination" [1]. However there are plenty of examples of compilers aggressively removing code that causes undefined behaviour. Basically, when the compiler encounters UB, it can do whatever it wants to code that triggers the UB, which means possibly removing it. Compilers exploit this fact a lot because UBs happen a lot in "normal code". See here [2] for examples and explanations; I also can't help but mention John Regehr's blog [3] if you're interested in compilers, security, testing, safety. [1] http://research.swtch.com/openssl http://research.swtch.com/openssl [2] http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-... [3] http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213 is a great article for example.
  - tedunangst 13y ago
    That doesn't seem like a good fit. It wasn't a compiler problem, it wasn't dead code, and the problem wasn't skipping zeroing, it was too much zeroing!

unuthu 13y ago

Umm, I think the person above is actually correct, though I'm by no means an expert. Otherwise, why would it take such a huge effort to achieve a deterministic build process as tor seems to have recently done?