4 ms·

Would be interesting to know how this affects Git version control, which has SHA-1 at its core.

by tux1968 12y ago

atonse 12y ago
This is for SSL and certificate validation - Google's move won't affect git in any way. Git uses it to ensure that the data that comes out is exactly what went in (like a much better checksum than md5 or crc32 etc). I don't know what the security implications are on the git side... I suppose an attacker could try to figure out how to change source code in a way that it preserves a commit log.
simias 12y ago
I assume you would need to forge a meaningful (and potentially harmful) commit with the same SHA-1 as an existing one to do arm. That's probably more difficult than forging an SSL certificate (since the actual contents of the blob are more constrained that the certificate file, probably). I'm also not really sure what would happen if commits made after the "compromised" one happened to conflict with it but I'm pretty sure the devs would notice something fishy going on pretty quickly. That being said git/mercurial and friends will have to transition to an other hashing algorithm sooner or later but it's not as urgent as web certificates security-wise.
- x1798DE 12y ago
  It seems to me like the time horizon for an attack on git based on SHA-1 collisions would be much, much longer than other similar collision attacks (like signing binary executables), because of the sequential nature of version control. Presumably the utility of such an attack would be to maliciously insert code into an earlier version of the code to hide its origins, in which case for each commit on the file, they'd need to calculate a collision that contains their changes plus whatever legitimate changes have been made to that file. I'm not familiar enough with the inner workings of git to know, but I imagine it would be a pain to juggle updating new commits from people working from a local copy of the repo - potentially your malfeasance would be detected quickly if you tried to calculate a diff between the old file and the new file from the local copy (which would presumably not be updated, given that the checksums match). That said, if people are in the habit of signing their tags/commits using SHA-1, then that would be just as vulnerable as any other signing problem.
- 0x0 12y ago
  I'd think the content of the blob is less constrained, because you can put whatever padding fluff you need at the end of the commit message to adjust the sha1 of the commit. To cause harm, you'd include the trojanized code in a different file which your colliding commit blob references. (So, you'd need to include multiple blobs, but only the commit-message one needs to collide with an existing one) A collision in commit hashes would mean you could no longer trust a signed tag, for example. Look up the old stripe-ctf "gitcoin" challenge and you'll see it really is quite easy to meddle with commit hashes :)
slavik81 12y ago
Google's decisions with respect to certificates don't really affect git much. But, if you're curious about how git handles pulling from repositories containing malicious hash collisions, Linus has talked about that in the past: > If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have. > So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. But note that "earlier" is obviously per-repository, in the sense that the git object network generates a DAG that is not fully ordered, so while different repositories will agree about what is "earlier" in the case of direct ancestry, if the object came through separate and not directly related branches, two different repos may obviously have gotten the two objects in different order. > However, the "earlier will override" is very much what you want from a security standpoint: remember that the git model is that you should primarily trust only your own repository. > So if you do a "git pull", the new incoming objects are by definition less trustworthy than the objects you already have, and as such it would be wrong to allow a new object to replace an old one. ... > in this case, the collision is entirely a non-issue: you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's literally no different from the attacker just not having found a collision at all, but just using the object you already had (ie it's 100% equivalent to the "trivial" collision of the identical file generating the same SHA1). http://stackoverflow.com/q/9392365 http://stackoverflow.com/q/9392365
- deleted 12y ago
  [deleted]

Would be interesting to know how this affects Git version control, which has SHA-1 at its core.

by tux1968 12y ago

Would be interesting to know how this affects Git version control, which has SHA-1 at its core.

This is for SSL and certificate validation - Google's move won't affect git in any way. Git uses it to ensure that the data that comes out is exactly what went in (like a much better checksum than md5 or crc32 etc). I don't know what the security implications are on the git side... I suppose an attacker could try to figure out how to change source code in a way that it preserves a commit log.

simias 12y ago

I assume you would need to forge a meaningful (and potentially harmful) commit with the same SHA-1 as an existing one to do arm. That's probably more difficult than forging an SSL certificate (since the actual contents of the blob are more constrained that the certificate file, probably). I'm also not really sure what would happen if commits made after the "compromised" one happened to conflict with it but I'm pretty sure the devs would notice something fishy going on pretty quickly. That being said git/mercurial and friends will have to transition to an other hashing algorithm sooner or later but it's not as urgent as web certificates security-wise.

x1798DE 12y ago
It seems to me like the time horizon for an attack on git based on SHA-1 collisions would be much, much longer than other similar collision attacks (like signing binary executables), because of the sequential nature of version control. Presumably the utility of such an attack would be to maliciously insert code into an earlier version of the code to hide its origins, in which case for each commit on the file, they'd need to calculate a collision that contains their changes plus whatever legitimate changes have been made to that file. I'm not familiar enough with the inner workings of git to know, but I imagine it would be a pain to juggle updating new commits from people working from a local copy of the repo - potentially your malfeasance would be detected quickly if you tried to calculate a diff between the old file and the new file from the local copy (which would presumably not be updated, given that the checksums match). That said, if people are in the habit of signing their tags/commits using SHA-1, then that would be just as vulnerable as any other signing problem.
0x0 12y ago
I'd think the content of the blob is less constrained, because you can put whatever padding fluff you need at the end of the commit message to adjust the sha1 of the commit. To cause harm, you'd include the trojanized code in a different file which your colliding commit blob references. (So, you'd need to include multiple blobs, but only the commit-message one needs to collide with an existing one) A collision in commit hashes would mean you could no longer trust a signed tag, for example. Look up the old stripe-ctf "gitcoin" challenge and you'll see it really is quite easy to meddle with commit hashes :)

slavik81 12y ago

Google's decisions with respect to certificates don't really affect git much. But, if you're curious about how git handles pulling from repositories containing malicious hash collisions, Linus has talked about that in the past: > If it has the same SHA1, it means that when we receive the object from the other end, we will not overwrite the object we already have. > So what happens is that if we ever see a collision, the "earlier" object in any particular repository will always end up overriding. But note that "earlier" is obviously per-repository, in the sense that the git object network generates a DAG that is not fully ordered, so while different repositories will agree about what is "earlier" in the case of direct ancestry, if the object came through separate and not directly related branches, two different repos may obviously have gotten the two objects in different order. > However, the "earlier will override" is very much what you want from a security standpoint: remember that the git model is that you should primarily trust only your own repository. > So if you do a "git pull", the new incoming objects are by definition less trustworthy than the objects you already have, and as such it would be wrong to allow a new object to replace an old one. ... > in this case, the collision is entirely a non-issue: you'll get a "bad" repository that is different from what the attacker intended, but since you'll never actually use his colliding object, it's literally no different from the attacker just not having found a collision at all, but just using the object you already had (ie it's 100% equivalent to the "trivial" collision of the identical file generating the same SHA1). http://stackoverflow.com/q/9392365 http://stackoverflow.com/q/9392365

deleted 12y ago
[deleted]