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.
next 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).