Jakub Narebski wrote:
Jakub Narebski <jnareb@xxxxxxxxx> writes:
Chris Frey <cdfrey@xxxxxxxxxxxxxx> writes:
Considering the recent news regarding SHA-1's newly found weaknesses,
is there any general interest in making git flexible enough to support
other hashes in the future?
First, there isn't as far as I know any 'known preimage' attack
against SHA-1, and only that would truly matter for Git.
Second, this issue was discussed in depth in the past; check git
mailing list archives, please...
See also this blog entry (and comments):
http://kitenet.net/~joey/blog/entry/sha-1/
It's a bit harder than that, since both pre-images have to be the same
size. Git does this when hashing an object to the database:
static void write_sha1_file_prepare(const void *buf, unsigned long len,
const char *type, unsigned char *sha1,
char *hdr, int *hdrlen)
{
git_SHA_CTX c;
/* Generate the header */
*hdrlen = sprintf(hdr, "%s %lu", type, len)+1;
/* Sha1.. */
git_SHA1_Init(&c);
git_SHA1_Update(&c, hdr, *hdrlen);
git_SHA1_Update(&c, buf, len);
git_SHA1_Final(sha1, &c);
}
Iow, the type and, more importantly, *size* of the object is added to
the hash. AFAIK, the pre-image conflict generators all rely on being
able to manipulate the size of the content it's creating hashes for.
I don't know how hard that would be to change, so perhaps someone else
can enlighten me.
I'm not exactly overwhelmed by the attack vectors Joey describes either.
First of all, it's rather trivial to add a check to git to make it
decompress its own internal object when it receives a conflicting hash
and then check the type, size and content of both objects and alert a
user if there is a mismatch somewhere. It wouldn't even burn that much
CPU, since conflicts are extremely rare without malevolent intervention.
That would defeat the first scenario by alerting users rather promptly.
The second scenario can't really be prevented, but unless Alice is
really a server-admin on the server hosting the repository, she will
leave traces in the ssh-logs. It also relies on the build-server being
utterly stupid by re-cloning the entire project.
Neither case is exactly foolproof. Both have a high risk of exposure.
A far better and simpler thing to do (if one were so inclined) would
be to just add whatever malicious code one wants but make it appear as
if it was added in a patch-series from someone else and then hope
noone notices until it's too late. Far less risk for the same gains.
As both vectors outlined by Joey require a lot of community trust, I'm
not particularly worried.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
http://nordicmeetonnagios.op5.org/
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html