5 ms·

I don't think even the NSA has people smart enough to insert code into a compiler which will add backdoors to software Really? Why wouldn't they? That's one

I don't think even the NSA has people smart enough to insert code into a compiler which will add backdoors to software Really? Why wouldn't they? That's one of the most valuable attack vectors, precisely because it's so difficult. I wouldn't have guessed the NSA had people smart enough to break Windows Update's encryption using a brand-new cryptographic technique that also required several hundred thousand dollars of machine time to execute, but it happened nonetheless. We have to start thinking ahead, e.g. by making deterministic builds a standard procedure: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise https://blog.torproject.org/blog/deterministic-builds-part-o...

ajross 13y ago
> Why wouldn't they? That's one of the most valuable attack vectors, precisely because it's so difficult. If this logic made any sense then we should just give up, as their megabit-scale quantum computers have already cracked all keys on the planet. My guess is you forgot the bit of the sentence you clipped.
- sillysaurus2 13y ago
  Deterministic builds do more than merely defend against the Trusting Trust attack (what you and cperciva are dismissing as a flight of fancy equivalent to worrying about megabit-scale quantum computers in 2013) --- they also prevent compromised open-source binaries, a much more serious and realistic attack vector. So we need to start implementing deterministic builds into every major open source project if we're even pretending like we care about putting up resistance to what's going on. If Tor browser can do it in just a few weekends, then so can we for mainstream Firefox, and hopefully eventually Ubuntu.
quasque 13y ago
> I wouldn't have guessed the NSA had people smart enough to break Windows Update's encryption using a brand-new cryptographic technique that also required several hundred thousand dollars of machine time to execute, but it happened nonetheless. That's rather unsettling. Do you have any further information on this?
- tedunangst 13y ago
  That's the "telephone game" retelling of the Flame virus.
- ivanr 13y ago
  sillysaurus2 is talking about the Flame malware, which used a previously unknown MD5 collision attack technique: http://blog.cryptographyengineering.com/2012/06/flame-certificates-collisions-oh-my.html http://blog.cryptographyengineering.com/2012/06/flame-certif... Why are you finding it unsettling? I think that's exactly what the NSA do: stay ahead of everyone else and take advantage of what they know. In this case, a different MD5 collision attack technique was invented by Marc Stevens at about the same time frame, so you couldn't even say that [whoever wrote Flame] was ahead by a lot. I have found it more interesting that they knew about the Microsoft design errors that they exploited to break the update mechanism. And, of course, wondered if the design errors were not forced.
anigbrowl 13y ago
Really? Why wouldn't they? That's one of the most valuable attack vectors, precisely because it's so difficult. You're assuming that because the NSA would like to have such a capability (as would most programmers), that they actually do, because they have abundant money to throw around. Likewise, I'm sure the Air Force, Army etc. would all like to have antigravity generators, and they have abundant money to throw at the problem, so they must have them, right? Of course not. 'A compiler that adds backdoors to software' implies a compiler that knows which routines are for security and which are not. How exactly is it to distinguish between get_string(super_sekrit_password) and get_string(pretty_background_color) for example? What if the background color is actually a way of revealing hidden messages, do you think it can see that coming? You're asking for a system which not only inserts unwanted code seamlessly into an application, but which can actually model the intention of the programmer and make decisions about how to compromise the code. From within the compiler running on a standard desktop or laptop, without noticeably extending compile times. I'm sorry, but given what a poor job humans do at turning specifications into code, the idea that there's a super-clever anti-security demon lurking inside every compiler is just laughable. And that's before the other obvious objection that looking at compiled code in a debugger/disassembler is going to reveal lumps of code that were not put there by the original author. Invisible on a sufficiently large project? Sure, but an encryption/decryption program doesn't need to be very large to begin with - all it has to do is to reliably transform a block of data into scrambled form and back again. This is more amenable to proof than most computer programs (not least because it has no need to be interactive). Furthermore, we can easily imagine test cases that are very very short; ROT-13 is a lousy cipher, but it is a cipher, and one that can be implemented in ~20 lines of (non-obfuscated) code. Now suppose we make a variant that asks the user how many places to rotate by (eg 14) and that number functions as our 'secret' key. Still hopelessly insecure to anyone over the age of 10, but what of it? Wouldn't your hypothesized 'insecurity demon' need to put a backdoor in anyway, because it is an encryption tool, be it ever so primitive? And wouldn't that block of code show up in a debugger? If your answer is no, you're now positing hidden functionality that not only divines programmers' intentions and subverts those that are intended to add security, but also looks at the quality of the security algorithm and only sticks in a backdoor if it passes a certain threshold of cleverness. I wish compilers had those smarts built in! Think how much tedious/craptacular code could be automated away by simply labeling things as 'sekrit!!' and having the NSA module inside the compiler generate lightweight, reliable code with no real penalty! It would take the pain out of unit testing for ever!
deleted 13y ago
[deleted]
pingswept 13y ago
Is the idea behind deterministic builds that you build the software on your own trusted system and then compare a hash of the binary with the hash the original builders got for their build? Thus you know that the binary you have must not contain any backdoors (or both binaries do)? I'm just trying to understand how it would work. How are deterministic builds better than distributing binaries with hashes for verification? Just because I don't have to trust the original author's compiler?
- sillysaurus2 13y ago
  How are deterministic builds better than distributing binaries with hashes for verification? Just because I don't have to trust the original author's compiler? Indeed, that's precisely why it's such an important protection mechanism. But it's about more than just not having to trust the original author's compiler. The original author might maliciously copy-paste some additional source code into the build process just before compilation. Deterministic builds are a way for any of us to download any source code, build it, and verify that all of us are using a binary derived from exactly that source code, and nothing else.
  - pingswept 13y ago
    Ah, I get it. Instead of relying on one guy, I can see that lots of different people who don't trust each other all agree that the binary hash should be X. Lots of people unknown to each other are unable to conspire to backdoor a binary. Cool. Thanks for the explanation. My first thought is that the next attack will be analogous to fake Amazon reviews. "This binary with the hash e99a12d388afa2fa5fdde8ed3bcbe055 gets five stars! After using 51fc8eff10b2fccec9890fe5d1b0cfd9 for years, I've realized that e99a12 is far superior in speed and robustness. I recommend you upgrade today!"

ajross 13y ago

> Why wouldn't they? That's one of the most valuable attack vectors, precisely because it's so difficult. If this logic made any sense then we should just give up, as their megabit-scale quantum computers have already cracked all keys on the planet. My guess is you forgot the bit of the sentence you clipped.

sillysaurus2 13y ago
Deterministic builds do more than merely defend against the Trusting Trust attack (what you and cperciva are dismissing as a flight of fancy equivalent to worrying about megabit-scale quantum computers in 2013) --- they also prevent compromised open-source binaries, a much more serious and realistic attack vector. So we need to start implementing deterministic builds into every major open source project if we're even pretending like we care about putting up resistance to what's going on. If Tor browser can do it in just a few weekends, then so can we for mainstream Firefox, and hopefully eventually Ubuntu.

quasque 13y ago

> I wouldn't have guessed the NSA had people smart enough to break Windows Update's encryption using a brand-new cryptographic technique that also required several hundred thousand dollars of machine time to execute, but it happened nonetheless. That's rather unsettling. Do you have any further information on this?

tedunangst 13y ago
That's the "telephone game" retelling of the Flame virus.
ivanr 13y ago
sillysaurus2 is talking about the Flame malware, which used a previously unknown MD5 collision attack technique: http://blog.cryptographyengineering.com/2012/06/flame-certificates-collisions-oh-my.html http://blog.cryptographyengineering.com/2012/06/flame-certif... Why are you finding it unsettling? I think that's exactly what the NSA do: stay ahead of everyone else and take advantage of what they know. In this case, a different MD5 collision attack technique was invented by Marc Stevens at about the same time frame, so you couldn't even say that [whoever wrote Flame] was ahead by a lot. I have found it more interesting that they knew about the Microsoft design errors that they exploited to break the update mechanism. And, of course, wondered if the design errors were not forced.

anigbrowl 13y ago

Really? Why wouldn't they? That's one of the most valuable attack vectors, precisely because it's so difficult. You're assuming that because the NSA would like to have such a capability (as would most programmers), that they actually do, because they have abundant money to throw around. Likewise, I'm sure the Air Force, Army etc. would all like to have antigravity generators, and they have abundant money to throw at the problem, so they must have them, right? Of course not. 'A compiler that adds backdoors to software' implies a compiler that knows which routines are for security and which are not. How exactly is it to distinguish between get_string(super_sekrit_password) and get_string(pretty_background_color) for example? What if the background color is actually a way of revealing hidden messages, do you think it can see that coming? You're asking for a system which not only inserts unwanted code seamlessly into an application, but which can actually model the intention of the programmer and make decisions about how to compromise the code. From within the compiler running on a standard desktop or laptop, without noticeably extending compile times. I'm sorry, but given what a poor job humans do at turning specifications into code, the idea that there's a super-clever anti-security demon lurking inside every compiler is just laughable. And that's before the other obvious objection that looking at compiled code in a debugger/disassembler is going to reveal lumps of code that were not put there by the original author. Invisible on a sufficiently large project? Sure, but an encryption/decryption program doesn't need to be very large to begin with - all it has to do is to reliably transform a block of data into scrambled form and back again. This is more amenable to proof than most computer programs (not least because it has no need to be interactive). Furthermore, we can easily imagine test cases that are very very short; ROT-13 is a lousy cipher, but it is a cipher, and one that can be implemented in ~20 lines of (non-obfuscated) code. Now suppose we make a variant that asks the user how many places to rotate by (eg 14) and that number functions as our 'secret' key. Still hopelessly insecure to anyone over the age of 10, but what of it? Wouldn't your hypothesized 'insecurity demon' need to put a backdoor in anyway, because it is an encryption tool, be it ever so primitive? And wouldn't that block of code show up in a debugger? If your answer is no, you're now positing hidden functionality that not only divines programmers' intentions and subverts those that are intended to add security, but also looks at the quality of the security algorithm and only sticks in a backdoor if it passes a certain threshold of cleverness. I wish compilers had those smarts built in! Think how much tedious/craptacular code could be automated away by simply labeling things as 'sekrit!!' and having the NSA module inside the compiler generate lightweight, reliable code with no real penalty! It would take the pain out of unit testing for ever!

deleted 13y ago

[deleted]

pingswept 13y ago

Is the idea behind deterministic builds that you build the software on your own trusted system and then compare a hash of the binary with the hash the original builders got for their build? Thus you know that the binary you have must not contain any backdoors (or both binaries do)? I'm just trying to understand how it would work. How are deterministic builds better than distributing binaries with hashes for verification? Just because I don't have to trust the original author's compiler?

sillysaurus2 13y ago
How are deterministic builds better than distributing binaries with hashes for verification? Just because I don't have to trust the original author's compiler? Indeed, that's precisely why it's such an important protection mechanism. But it's about more than just not having to trust the original author's compiler. The original author might maliciously copy-paste some additional source code into the build process just before compilation. Deterministic builds are a way for any of us to download any source code, build it, and verify that all of us are using a binary derived from exactly that source code, and nothing else.
- pingswept 13y ago
  Ah, I get it. Instead of relying on one guy, I can see that lots of different people who don't trust each other all agree that the binary hash should be X. Lots of people unknown to each other are unable to conspire to backdoor a binary. Cool. Thanks for the explanation. My first thought is that the next attack will be analogous to fake Amazon reviews. "This binary with the hash e99a12d388afa2fa5fdde8ed3bcbe055 gets five stars! After using 51fc8eff10b2fccec9890fe5d1b0cfd9 for years, I've realized that e99a12 is far superior in speed and robustness. I recommend you upgrade today!"