4 ms·

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 th

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
  - layer8 4y ago
    There is a middle course: You could get a pull request accepted with good content, but including a sensible comment whose exact wording you can choose, so later you can replace the contents of that commit with malicious code and a garbage comment. Such a collision is easier to create than a preimage attack (because you have some control over the preimage), but harder than if you could choose the preimage arbitrarily (which wouldn’t be accepted in the pull request). I admit that I have no idea how to quantify the difference in difficulty.
avar 4y ago
(I'm the "Bjarmason" quoted in the article) To elaborate a bit: One thing that makes a viable attack against Git especially hard is that aside from the hash it's using has a behavior of never replacing an already hashed object[1]. So let's say I have a tool that can take a given file & SHA-1 pair and produce a collision, the next step is quite hard. I could in this scenario produce a file with an exploit whose hash matches that of Linus's kernel/pid.c or whatever. But how do I get that object to propagate among forks of linux.git to distribute my exploited code? If I e.g. push it to a fork of linux.git on a hosting provider that Linus uses the the remote "git-index-pack" process will hash my colliding object, but before it stores it check whether such an object ID exists in its object store, if it does it'll drop it on the floor. You don't need to store data you've already got in a content-addressable filesystem. Which is not to say that a hash collision is a non-issue, and Git should certainly be migrating from SHA-1. There's no disagreement about that in the Git development community. But it matters for how much you should panic how the software you're using could be exploited in the case of a hash collision. Also, the scenario above presupposes a preimage attack, which is a much worse attack on a hash function than a collision attack. Currently no viable preimage attack on SHA-1 exists, only a collision attack. Which means that before any of the above I'd have to have produced a viable version of say kernel/pid.c that Linus was willing to merge, knowing that my evil twin of that version is something I intended to exploit people with. Then I'd need to patiently wait for that version to make it into a release, knowing that even a one-byte change to the file would foil my plans... 1. On the topic of running with scissors: I wrote a patch to disable that collision check for an ex employer, it helped in that I/O-bound setup, and we were confident in the lessened security being a non-issue for us in that particular setup. The patch never made it into git's mainline. The patch won't apply anymore, but the embedded docs elaborate on the topic: https://lore.kernel.org/git/20181113201910.11518-1-avarab@gmail.com/ https://lore.kernel.org/git/20181113201910.11518-1-avarab@gm...;
- mvkg 4y ago
  Regarding the collision attack replacement check, do you know if that is carried over into other git implementations (e.g. libgit2)?
  - 4y ago

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
- layer8 4y ago
  There is a middle course: You could get a pull request accepted with good content, but including a sensible comment whose exact wording you can choose, so later you can replace the contents of that commit with malicious code and a garbage comment. Such a collision is easier to create than a preimage attack (because you have some control over the preimage), but harder than if you could choose the preimage arbitrarily (which wouldn’t be accepted in the pull request). I admit that I have no idea how to quantify the difference in difficulty.

avar 4y ago

(I'm the "Bjarmason" quoted in the article) To elaborate a bit: One thing that makes a viable attack against Git especially hard is that aside from the hash it's using has a behavior of never replacing an already hashed object[1]. So let's say I have a tool that can take a given file & SHA-1 pair and produce a collision, the next step is quite hard. I could in this scenario produce a file with an exploit whose hash matches that of Linus's kernel/pid.c or whatever. But how do I get that object to propagate among forks of linux.git to distribute my exploited code? If I e.g. push it to a fork of linux.git on a hosting provider that Linus uses the the remote "git-index-pack" process will hash my colliding object, but before it stores it check whether such an object ID exists in its object store, if it does it'll drop it on the floor. You don't need to store data you've already got in a content-addressable filesystem. Which is not to say that a hash collision is a non-issue, and Git should certainly be migrating from SHA-1. There's no disagreement about that in the Git development community. But it matters for how much you should panic how the software you're using could be exploited in the case of a hash collision. Also, the scenario above presupposes a preimage attack, which is a much worse attack on a hash function than a collision attack. Currently no viable preimage attack on SHA-1 exists, only a collision attack. Which means that before any of the above I'd have to have produced a viable version of say kernel/pid.c that Linus was willing to merge, knowing that my evil twin of that version is something I intended to exploit people with. Then I'd need to patiently wait for that version to make it into a release, knowing that even a one-byte change to the file would foil my plans... 1. On the topic of running with scissors: I wrote a patch to disable that collision check for an ex employer, it helped in that I/O-bound setup, and we were confident in the lessened security being a non-issue for us in that particular setup. The patch never made it into git's mainline. The patch won't apply anymore, but the embedded docs elaborate on the topic: https://lore.kernel.org/git/20181113201910.11518-1-avarab@gmail.com/ https://lore.kernel.org/git/20181113201910.11518-1-avarab@gm...;

mvkg 4y ago
Regarding the collision attack replacement check, do you know if that is carried over into other git implementations (e.g. libgit2)?
- 4y ago