git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Hirshleifer <111mth@caltech.edu>
To: git@vger.kernel.org
Subject: Possible vulnerability to SHA-1 collisions
Date: Sat, 24 Nov 2012 11:12:28 +0000	[thread overview]
Message-ID: <50B0AB9C.2040802@caltech.edu> (raw)

Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1 
checksum (including Git header). Mr. Evil creates a local branch with an 
innocuous name like “test-bugfix”, and adds a commit containing a 
reference to the evil file. Separately, using a sockpuppet, Evil Guy 
creates an innocuous bugfix (very likely to be accepted) containing the 
innocuous file, and submits it to Good Guy. Before Good Guy can commit 
the bugfix, Evil Guy pushes the evil branch to Github, and then 
immediately deletes it; or equivalently --force pushes any innocuous 
commit on top of it. (This is unlikely to arouse suspicion, and he can 
always say he deleted it because it didn’t work.)

Git keeps unreferenced objects around for a few weeks, so when Good Guy 
commits the patch and pushes to Github, an object with an sha1sum that 
matches the good file will already exist in the main repository. Since 
Git keeps the local copy of files when sha1sums match, the main Github 
repository will then contain the evil file associated with Good Guy’s 
commit. Any users cloning from Github will get the evil version. This is 
an exploit.

And Good Guy’s local repository will contain the good file; he will not 
notice anything amiss unless he nukes his local repository and clones 
from Github again. Even when the compromise is discovered, there will be 
no reason to suspect Evil Guy; the evil file seems to have been 
committed by Good Guy.

Previous discussion about hash collisions in Git seems to conclude that 
they aren’t a security threat. See 
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob/9392525#9392525, 
Linus Torvalds arguing that Git’s security doesn’t depend on SHA-1 
collision resistance.

This proposed exploit does not involve social engineering, or any good 
guys failing to spot or accepting patches containing evil data (what 
Good Guy accepts is a genuine bugfix). It contaminates the main public 
repository in a way that Good Guy won’t immediately notice. It does not 
require a second-preimage attack; Bad Guy creates both versions of the 
file. While this does require the bad guy to have commit access, the bad 
guy can avoid suspicion after the attack.

             reply	other threads:[~2012-11-24 11:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-24 11:12 Michael Hirshleifer [this message]
2012-11-24 18:09 ` Possible vulnerability to SHA-1 collisions Shawn Pearce
2012-11-27 23:07   ` Jeff King
2012-11-27 23:30     ` Aaron Schrab
2012-11-28  0:27       ` Jeff King
2012-11-28  9:35         ` Andreas Ericsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B0AB9C.2040802@caltech.edu \
    --to=111mth@caltech.edu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).