As GIT uses SHA-1 signatures to uniquely identify objects you might ask yourself if it is still safe to store objects in your GIT code archive.
Let’s find out!
First, SHA-1 signatures are used in GIT to ensure data integrity and consistency to detect corruption by DRAM or disks etc.
However, it was never implemented as a security feature to keep attackers out. For that purpose other mechanism have been implemented in GIT: signed commits.
While in 2012 it was predicted it would take approx. $2.7M (source) to break a single hash value it can now (fall 2015) be done with a budget of $100.000 by renting CPU from a cloud provider like Amazon EC2.
If you are curious how a SHA-1 hash of an object or text string looks like you can do this by executing the following line in a DOS command window:
C:\>echo 'tmcatlassian.nl' | git hash-object --stdin 305a612381941ed40cf03da15bd3332d262e5e1c |
Now, let’s assume the attacker is attacking a remote repository.
When the attacker has access to a local repository there are probably much easier and cheaper ways to inject code into a GIT repository, so this is the logical scenario.
The attacker created a file containing malicious code with an identical SHA-1 and committed it to the remote repository.
Now what happens is that the new object will not be created!
Since the malicious file that the hacker wants to inject has the same SHA-1 has the original file in your repository the commit or GIT index ends up pointing to the old object.
GIT thinks you have committed the same object as it has an identical SHA-1 hash.
Bottom line is that SHA-1 collisions are not very relevant for existing GIT repositories. Use signed commit messages for extra security instead.
