5 ms·

Does the usage of SHA-1 in Git actually have security implications, though? It's basically only used to generate addresses for refs and hunks and all that.

by bradhe 4y ago

saghm 4y ago
I don't think it does; sure, someone could potentially craft a malicious commit that causes a SHA1 collision in your repo, but I think if you are merging commits from malicious authors, you've got way bigger problems than that.
- corbet 4y ago
  ...and if you're merging commits from a developer who, unknown to either of you, had their laptop compromised and their repo corrupted? Remember that the compromise of kernel.org happened via a developer's laptop, and it was only the security of the hash chains that preserved confidence in the repositories stored there. As noted in the article, an SHA-1 collision attack does not appear practical now, but that is a situation that can change.
- shakna 4y ago
  GitHub actually makes pull requests available as an unlisted part of the original repository under refs/pull/$PR/head and refs/pull/$PR/merge, which allows a malicious author to add themselves to your index, without your involvement. Not to say that this attack is in any way practical, yet. Just that some providers don't require active involvement to try and attempt it.
mmastrac 4y ago
If a repo accepts third-party contributions, you can create a split brain where half the people see one set of contents and the others see a different set, but the same hashes are available. I don't know if this would survive additional commits on top as I'm not familiar enough with git's internals.
- progval 4y ago
  It will survive it until someone touches the affected blob, then they'll converge to the version that person has.
blakesterz 4y ago
The article does address that: "Given the threat that the SHA-1 hash poses, one might think that there would be a stronger incentive for somebody to support this work. But, as Bjarmason continued, that incentive is not actually all that strong. The project adopted the SHA-1DC variant of SHA-1 for the 2.13 release in 2017, which makes the project more robust against the known SHA-1 collision attacks, so there does not appear to be any sort of imminent threat of this type of attack against Git. Even if creating a collision were feasible for an attacker, Bjarmason pointed out, that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that has the functionality the attacker is after, and that looks reasonable to both humans and compilers is quite a bit harder — if it is possible at all."
- Salgat 4y ago
  From what I've heard it's as simple as injecting the necessary garbage into a comment to fit the required hash for modified code.
  - jandrese 4y ago
    The comment full of random garbage will probably look weird to a human, but by the time a person is looking at the code it will probably be too late. But you could also hide it as a fake lookup table or inline XPM or something like that.
  - prepend 4y ago
    > as simple as injecting the necessary garbage into a comment to fit the required hash for modified code. This seems true yet there are no demos or documented attacks using this method. I think practically speaking it’s kind of a pain to do.
  - bawolff 4y ago
    There is a big difference between having 2 file with the same garbage comment but different content that have the same hash and creating a new file that had a garbage comment and has the same hash as some other file not chosen by the attacker. (preimage vs collision). Sha1 has a collision attack. We are far away from a preimage attack
nonameiguess 4y ago
It's difficult to exploit, but possible. I think the actual issue here is environment accreditation not allowing the use of sha-1 at all, but that is still rare. It'll become a much larger issue if a future FIPS standard ever disallows sha-1, because that will impact a ton of environments. It means git won't even work on your servers any more.
Zamicol 4y ago
This is concerning from a signing perspective. Example: `git commit -a -S -m 'signed commit'` signs the SHA-1 hash directly. Even if the SHA-1 digest is rehashed with a secure hashing algorithm, SHA-256, it would hide the fact that the reference is to an insecure hashing algorithm. The project itself needs to be rehashed with a secure hashing algorithm for signing to be secure.
- Dylan16807 4y ago
  It's more complicated than that. If the most recent signatures are entirely based on SHA-256, and you trust those signatures sufficiently, then they act as protection for all ancestor commits. In that case a SHA1-based signature on an older commit isn't a big deal.
  - Zamicol 4y ago
    >then they act as protection for all ancestor commits How does that work? My understanding was that a git gpg signature only signs the project at that commit state. It says nothing about past (or future) commits outside of a digest reference to past commits, which if that digest wasn't upgraded, would be considered insecure. Said another way: Git does not rehash past commits, or the present commit, when gpg signing. A commit itself only includes the SHA-1 digest of the previous commit.
    - Dylan16807 4y ago
      If you convert a repo to SHA-256, then surely it will recalculate all the hashes back to the start, right? Otherwise that's not a conversion. And then new signatures will use a hash that's SHA-256 all the way down. The old signatures will still be SHA-1. But if you try to replace any part of a commit, the SHA-256 won't match. So the combination of "the commit is an ancestor of multiple securely signed commits in this repo" and "the SHA1 on the signature matches" is enough to know you have the right data in most use cases.
    - layer8 4y ago
      You are correct. In the AdES signature world, the solution is to have a cryptographic (signed) timestamp using a newer hash algorithm that rehashes all previous commits, and to include that timestamp into a new commit. When verifying the hashes of old commits, the software would verify that those are covered by an appropriate timestamp that proves that they were created before the old hash algorithm was considered too weak. This is very similar to the following: Instead of rehashing, i.e. replacing old hashes with new hashes, add the new hashes alongside the old ones, and sign the new hashes, together with the time mark, by a trusted authority. The old hashes and signatures then remain valid indefinitely as long as the new hashes and signatures are verified successfully.

Does the usage of SHA-1 in Git actually have security implications, though? It's basically only used to generate addresses for refs and hunks and all that.

by bradhe 4y ago

Does the usage of SHA-1 in Git actually have security implications, though? It's basically only used to generate addresses for refs and hunks and all that.

saghm 4y ago

I don't think it does; sure, someone could potentially craft a malicious commit that causes a SHA1 collision in your repo, but I think if you are merging commits from malicious authors, you've got way bigger problems than that.

corbet 4y ago
...and if you're merging commits from a developer who, unknown to either of you, had their laptop compromised and their repo corrupted? Remember that the compromise of kernel.org happened via a developer's laptop, and it was only the security of the hash chains that preserved confidence in the repositories stored there. As noted in the article, an SHA-1 collision attack does not appear practical now, but that is a situation that can change.
shakna 4y ago
GitHub actually makes pull requests available as an unlisted part of the original repository under refs/pull/$PR/head and refs/pull/$PR/merge, which allows a malicious author to add themselves to your index, without your involvement. Not to say that this attack is in any way practical, yet. Just that some providers don't require active involvement to try and attempt it.

mmastrac 4y ago

If a repo accepts third-party contributions, you can create a split brain where half the people see one set of contents and the others see a different set, but the same hashes are available. I don't know if this would survive additional commits on top as I'm not familiar enough with git's internals.

progval 4y ago
It will survive it until someone touches the affected blob, then they'll converge to the version that person has.

blakesterz 4y ago

The article does address that: "Given the threat that the SHA-1 hash poses, one might think that there would be a stronger incentive for somebody to support this work. But, as Bjarmason continued, that incentive is not actually all that strong. The project adopted the SHA-1DC variant of SHA-1 for the 2.13 release in 2017, which makes the project more robust against the known SHA-1 collision attacks, so there does not appear to be any sort of imminent threat of this type of attack against Git. Even if creating a collision were feasible for an attacker, Bjarmason pointed out, that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that has the functionality the attacker is after, and that looks reasonable to both humans and compilers is quite a bit harder — if it is possible at all."

Salgat 4y ago
From what I've heard it's as simple as injecting the necessary garbage into a comment to fit the required hash for modified code.
- jandrese 4y ago
  The comment full of random garbage will probably look weird to a human, but by the time a person is looking at the code it will probably be too late. But you could also hide it as a fake lookup table or inline XPM or something like that.
- prepend 4y ago
  > as simple as injecting the necessary garbage into a comment to fit the required hash for modified code. This seems true yet there are no demos or documented attacks using this method. I think practically speaking it’s kind of a pain to do.
- bawolff 4y ago
  There is a big difference between having 2 file with the same garbage comment but different content that have the same hash and creating a new file that had a garbage comment and has the same hash as some other file not chosen by the attacker. (preimage vs collision). Sha1 has a collision attack. We are far away from a preimage attack

nonameiguess 4y ago

It's difficult to exploit, but possible. I think the actual issue here is environment accreditation not allowing the use of sha-1 at all, but that is still rare. It'll become a much larger issue if a future FIPS standard ever disallows sha-1, because that will impact a ton of environments. It means git won't even work on your servers any more.

Zamicol 4y ago

This is concerning from a signing perspective. Example: `git commit -a -S -m 'signed commit'` signs the SHA-1 hash directly. Even if the SHA-1 digest is rehashed with a secure hashing algorithm, SHA-256, it would hide the fact that the reference is to an insecure hashing algorithm. The project itself needs to be rehashed with a secure hashing algorithm for signing to be secure.

Dylan16807 4y ago
It's more complicated than that. If the most recent signatures are entirely based on SHA-256, and you trust those signatures sufficiently, then they act as protection for all ancestor commits. In that case a SHA1-based signature on an older commit isn't a big deal.
- Zamicol 4y ago
  >then they act as protection for all ancestor commits How does that work? My understanding was that a git gpg signature only signs the project at that commit state. It says nothing about past (or future) commits outside of a digest reference to past commits, which if that digest wasn't upgraded, would be considered insecure. Said another way: Git does not rehash past commits, or the present commit, when gpg signing. A commit itself only includes the SHA-1 digest of the previous commit.
  - Dylan16807 4y ago
    If you convert a repo to SHA-256, then surely it will recalculate all the hashes back to the start, right? Otherwise that's not a conversion. And then new signatures will use a hash that's SHA-256 all the way down. The old signatures will still be SHA-1. But if you try to replace any part of a commit, the SHA-256 won't match. So the combination of "the commit is an ancestor of multiple securely signed commits in this repo" and "the SHA1 on the signature matches" is enough to know you have the right data in most use cases.
  - layer8 4y ago
    You are correct. In the AdES signature world, the solution is to have a cryptographic (signed) timestamp using a newer hash algorithm that rehashes all previous commits, and to include that timestamp into a new commit. When verifying the hashes of old commits, the software would verify that those are covered by an appropriate timestamp that proves that they were created before the old hash algorithm was considered too weak. This is very similar to the following: Instead of rehashing, i.e. replacing old hashes with new hashes, add the new hashes alongside the old ones, and sign the new hashes, together with the time mark, by a trusted authority. The old hashes and signatures then remain valid indefinitely as long as the new hashes and signatures are verified successfully.