4 ms·

Fortunately, the attackers didn't, or weren't able to, use their access to slip backdoor code into the OpenSSL software, which websites around the world use to

Fortunately, the attackers didn't, or weren't able to, use their access to slip backdoor code into the OpenSSL software, which websites around the world use to provide HTTPS encryption for the pages they serve. That assurance is possible because the code is maintained and distributed through Git, a source-code management system that allows developers and users to maintain independent copies all over the Internet. Since the cryptographic hashes found on OpenSSL matched those elsewhere, there is a high degree of confidence the code hasn't been altered. A few days ago I posed the question of whether Git's crypto is an example of dangerous amateur cryptography, since Linus isn't (AFAIK) a crypto expert: https://news.ycombinator.com/item?id=6961683 https://news.ycombinator.com/item?id=6961683 The general answer I got was that Git isn't really crypto, because it isn't using the hash to guarantee integrity, but simply as a checksum to detect corruption. I didn't find this argument very convincing at the time, and I would now offer the above quotation as evidence that people do in fact treat Git's hashes as a security mechanism that can withstand an adversarial attack.

ams6110 13y ago
detecting corruption is pretty much the same thing as detecting changes though right? Git uses SHA-1 hashes (I think). If someone managed to change the code in a way that still properly compiles AND doesn't change the checksum hash, well... pretty unlikely.
- 0x0 13y ago
  Not at all unlikely. Plenty of places to put adjustment bits to correct into a hash collision, like in comments, firmware blobs, unused files. One of the md5 collision examples from earlier was two postscript files that both parsed fine but had different messages.
  - a-nom-a-ly 13y ago
    You might have a point regarding binary blobs but, IMO, if they can alter text(comments, source, etc.) in such a way that it's not obvious to the human reviewer, then they deserve to succeed. I don't know what `unused files` means. Git used `sha1` last time I checked, so I'm not sure why you mention `md5`.
    - 0x0 13y ago
      Unused files: there are always plenty of files in a source distribution that aren't actually being used during a compile, for example a README file. As far as I know a commit id is a sha sum of a tree of files, so you could probably put any "adjusting bits" in an unimportant file. Md5: Just an example of how hash collisions can work in real life (not aware of any published sha1 examples)
- MaulingMonkey 13y ago
  It's pretty much the same thing as detecting unintentional changes - very important distinction! Something like CRC32 might catch some 99.999% of the cases of unintentional corruption. But you could probably figure out how to generate a collision using pen and paper, without being a cryptography expert of any sort, in which case CRC32 will only catch the cases where you forget to carry a one! EDIT: SHA1's naturally a bit tougher to beat than CRC32, but there's plenty of whitespace and comments and identifiers to rename without affecting the execution of a program. Your typical binary format will have plenty of uninitialized padding bytes to tweak as well. Plenty of room to change unimportant data to generate a collision.
  - ams6110 13y ago
    OK, so I think "a bit tougher" is an understatement to say the least. If they're really worried, compare file sizes too. Then compile the code and verify that the checksum on the executable is the same as before. I just think it would be really hard to pull this off, maybe the NSA could do it but they wouldn't have tipped their hand by defacing the site too.
    - MaulingMonkey 13y ago
      > OK, so I think "a bit tougher" is an understatement to say the least. Sure. But the point is that a detecting corruption is a far different beast than detecting intentional collision attempts. > If they're really worried, compare file sizes too. This adds nearly no security. > Then compile the code and verify that the checksum on the executable is the same as before. Compare the whole binary! If you don't trust a SHA1 on the source, trusting a SHA1 on the binary is merely moving the goalposts around. This also requires deterministic builds - this isn't the default or necessairly easy, but it's possible and is the approach the TOR project takes at least: https://blog.torproject.org/category/tags/deterministic-builds https://blog.torproject.org/category/tags/deterministic-buil... Alternatively, even without deterministic builds, compare the whole source tree! The whole file must be read to compute the hash in the first place, so why not compare all those bytes? > I just think it would be really hard to pull this off And while I would agree with you on that point, the point I'm trying to make is simply that this has absolutely nothing to do with the fact that git attempts to detect accidental corruption -- the specifics are paramount! While SHA1 is not the weakest cryptographic hash, it is not the strongest cryptographic hash either. Git was not designed to focus on cryptographic security, and it was written by a programmer who is not a cryptographic security expert. I would also stress that "really hard" is quite different from "impossible" (an in the general case, quite different from even "unlikely".) (That said, sneaking in a benign-looking backdoor through standard channels sounds way easier.)
Karunamon 13y ago
Indeed. Assuming the rest of the code is implemented without any vulnerabilities (and that's one hell of an assumption about any code), SHA1, which Git uses as its hashing algorithm, has been completely broken as early as 2005[1]. That said, I'm not sure how you'd go about crafting source code in such a way as to collide with a known hash without it being amazingly obvious. You could change history to make it appear as if your crocked code was always there or had been for a long time, but then you don't have to figure just one hash, then you have to figure every single hash down to the parent. Depending on the number of commits, that's a hell of a lot of work, even with an algorithm to break SHA1. And even then if you change the hashes, since Git is distributed, the developers will quickly figure out that what's in one repo doesn't match all the others when patches start breaking.. [1] - https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html https://www.schneier.com/blog/archives/2005/02/cryptanalysis...
- yuhong 13y ago
  To be honest, git dates back to 2004, when SHA256 was a fairly recent invention.
- insaneirish 13y ago
  Your definition of "completely broken" is misleading. While it makes complete sense to use SHA-256 and beyond, a collision of two carefully constructed plaintexts is not indicative of a general break in SHA-1. It is much more difficult to find a collision against a fixed plaintext and hash and ridiculously more difficult for that collision to produce non-gibberish, working code that compiles and creates a vulnerability.
  - darklajid 13y ago
    I'm no expert, at all. Reading your list of complications though I wonder if the last one is really a problem? Hiding a vulnerability that doesn't look suspicious on first sight? Agreed. But hiding a vulnerability at all - if compiled without reading the source? Isn't that 'just' appending /* garbage */ or even code in IFDEFs? In other words: Is the last point really an issue or is it 'just' a collection against a fixed plaintext/hash?
cliffbean 13y ago
You're right. Git really isn't crypto, and this news blurb does sound a bit odd. Hopefully this is just a misunderstanding in the reporting. Matching hashes is probably a pretty good sanity check, but it isn't the kind of solid guarantee that a project like OpenSSL needs. Fortunately, one great thing about decentralized source control systems is that everyone has a copy of everything. Hopefully someone has simply located a repository which hasn't been updated since before the breach, and done some direct comparisons.
DannyBee 13y ago
Git's hashes were not always verified all that often in the past (at least, as of 1.7.4.1): http://stackoverflow.com/questions/5585388/which-git-commands-perform-integrity-checks http://stackoverflow.com/questions/5585388/which-git-command... You'll see plenty of operations do not check the sha1, and will happily hand you bad data, including checkout and clone, depending on circumstances. I haven't checked on the latest version, but at least previously, you'd have to run around using git fsck specifically to get it to notice some sha1 mismatches. So at least trivially, the idea that "it uses sha-1 so it's safe" is silly even without considering the implementation, because it doesn't always check the sha-1 :) (I'm not even going to argue it should, just pointing out it didn't) You can also GPG sign git commits (see http://mikegerwitz.com/papers/git-horror-story.html http://mikegerwitz.com/papers/git-horror-story.html for a long explanation of what does and does not get checked)

ams6110 13y ago

detecting corruption is pretty much the same thing as detecting changes though right? Git uses SHA-1 hashes (I think). If someone managed to change the code in a way that still properly compiles AND doesn't change the checksum hash, well... pretty unlikely.

0x0 13y ago
Not at all unlikely. Plenty of places to put adjustment bits to correct into a hash collision, like in comments, firmware blobs, unused files. One of the md5 collision examples from earlier was two postscript files that both parsed fine but had different messages.
- a-nom-a-ly 13y ago
  You might have a point regarding binary blobs but, IMO, if they can alter text(comments, source, etc.) in such a way that it's not obvious to the human reviewer, then they deserve to succeed. I don't know what `unused files` means. Git used `sha1` last time I checked, so I'm not sure why you mention `md5`.
  - 0x0 13y ago
    Unused files: there are always plenty of files in a source distribution that aren't actually being used during a compile, for example a README file. As far as I know a commit id is a sha sum of a tree of files, so you could probably put any "adjusting bits" in an unimportant file. Md5: Just an example of how hash collisions can work in real life (not aware of any published sha1 examples)
MaulingMonkey 13y ago
It's pretty much the same thing as detecting unintentional changes - very important distinction! Something like CRC32 might catch some 99.999% of the cases of unintentional corruption. But you could probably figure out how to generate a collision using pen and paper, without being a cryptography expert of any sort, in which case CRC32 will only catch the cases where you forget to carry a one! EDIT: SHA1's naturally a bit tougher to beat than CRC32, but there's plenty of whitespace and comments and identifiers to rename without affecting the execution of a program. Your typical binary format will have plenty of uninitialized padding bytes to tweak as well. Plenty of room to change unimportant data to generate a collision.
- ams6110 13y ago
  OK, so I think "a bit tougher" is an understatement to say the least. If they're really worried, compare file sizes too. Then compile the code and verify that the checksum on the executable is the same as before. I just think it would be really hard to pull this off, maybe the NSA could do it but they wouldn't have tipped their hand by defacing the site too.
  - MaulingMonkey 13y ago
    > OK, so I think "a bit tougher" is an understatement to say the least. Sure. But the point is that a detecting corruption is a far different beast than detecting intentional collision attempts. > If they're really worried, compare file sizes too. This adds nearly no security. > Then compile the code and verify that the checksum on the executable is the same as before. Compare the whole binary! If you don't trust a SHA1 on the source, trusting a SHA1 on the binary is merely moving the goalposts around. This also requires deterministic builds - this isn't the default or necessairly easy, but it's possible and is the approach the TOR project takes at least: https://blog.torproject.org/category/tags/deterministic-builds https://blog.torproject.org/category/tags/deterministic-buil... Alternatively, even without deterministic builds, compare the whole source tree! The whole file must be read to compute the hash in the first place, so why not compare all those bytes? > I just think it would be really hard to pull this off And while I would agree with you on that point, the point I'm trying to make is simply that this has absolutely nothing to do with the fact that git attempts to detect accidental corruption -- the specifics are paramount! While SHA1 is not the weakest cryptographic hash, it is not the strongest cryptographic hash either. Git was not designed to focus on cryptographic security, and it was written by a programmer who is not a cryptographic security expert. I would also stress that "really hard" is quite different from "impossible" (an in the general case, quite different from even "unlikely".) (That said, sneaking in a benign-looking backdoor through standard channels sounds way easier.)

Karunamon 13y ago

Indeed. Assuming the rest of the code is implemented without any vulnerabilities (and that's one hell of an assumption about any code), SHA1, which Git uses as its hashing algorithm, has been completely broken as early as 2005[1]. That said, I'm not sure how you'd go about crafting source code in such a way as to collide with a known hash without it being amazingly obvious. You could change history to make it appear as if your crocked code was always there or had been for a long time, but then you don't have to figure just one hash, then you have to figure every single hash down to the parent. Depending on the number of commits, that's a hell of a lot of work, even with an algorithm to break SHA1. And even then if you change the hashes, since Git is distributed, the developers will quickly figure out that what's in one repo doesn't match all the others when patches start breaking.. [1] - https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html https://www.schneier.com/blog/archives/2005/02/cryptanalysis...

yuhong 13y ago
To be honest, git dates back to 2004, when SHA256 was a fairly recent invention.
insaneirish 13y ago
Your definition of "completely broken" is misleading. While it makes complete sense to use SHA-256 and beyond, a collision of two carefully constructed plaintexts is not indicative of a general break in SHA-1. It is much more difficult to find a collision against a fixed plaintext and hash and ridiculously more difficult for that collision to produce non-gibberish, working code that compiles and creates a vulnerability.
- darklajid 13y ago
  I'm no expert, at all. Reading your list of complications though I wonder if the last one is really a problem? Hiding a vulnerability that doesn't look suspicious on first sight? Agreed. But hiding a vulnerability at all - if compiled without reading the source? Isn't that 'just' appending /* garbage */ or even code in IFDEFs? In other words: Is the last point really an issue or is it 'just' a collection against a fixed plaintext/hash?

cliffbean 13y ago

You're right. Git really isn't crypto, and this news blurb does sound a bit odd. Hopefully this is just a misunderstanding in the reporting. Matching hashes is probably a pretty good sanity check, but it isn't the kind of solid guarantee that a project like OpenSSL needs. Fortunately, one great thing about decentralized source control systems is that everyone has a copy of everything. Hopefully someone has simply located a repository which hasn't been updated since before the breach, and done some direct comparisons.

DannyBee 13y ago

Git's hashes were not always verified all that often in the past (at least, as of 1.7.4.1): http://stackoverflow.com/questions/5585388/which-git-commands-perform-integrity-checks http://stackoverflow.com/questions/5585388/which-git-command... You'll see plenty of operations do not check the sha1, and will happily hand you bad data, including checkout and clone, depending on circumstances. I haven't checked on the latest version, but at least previously, you'd have to run around using git fsck specifically to get it to notice some sha1 mismatches. So at least trivially, the idea that "it uses sha-1 so it's safe" is silly even without considering the implementation, because it doesn't always check the sha-1 :) (I'm not even going to argue it should, just pointing out it didn't) You can also GPG sign git commits (see http://mikegerwitz.com/papers/git-horror-story.html http://mikegerwitz.com/papers/git-horror-story.html for a long explanation of what does and does not get checked)