Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

From: Conrad Meyer <cem_at_freebsd.org>
Date: Mon, 4 Jan 2021 17:25:38 -0800
On Mon, Jan 4, 2021 at 1:44 PM Ryan Stone <rysto32_at_gmail.com> wrote:
> FWIW, a coworker of mine had a little hobby of introducing commits
> into our internal repro that had hashes that all started with
> deadc0de.  As I understand it, it was able to do this by adding an
> bogus attribute with the right value to the commit object.

Yeah, the git commit object is essentially text with some headers, and
the git tools are all permissive of unrecognized headers.  You can
create a "visually identical" commit (same commit message, parent
commit(s), author/committer/dates, etc) by just adding an extra header
with an arbitrary value and brute force on that value to find a vanity
prefix.  This isn't anything related to the SHA1 attacks, it's just
brute-forcing the output of a truncated SHA1 to a 1-in-2^32 result.

E.g., https://github.com/cemeyer/gitbrutec does it by injecting a
header named "x-gitbrutec-nonce."

$ git cat-file -p 0000009
tree 4e778673b8af45ecd4c62e8b1d1438d06db7f440
parent 00000080b4fc4c2066fa05641e73d5f0985c15ea
author Conrad Meyer <cem_at_FreeBSD.org> 1590357489 -0700
committer Conrad Meyer <cem_at_FreeBSD.org> 1590357489 -0700
x-gitbrutec-nonce YYZSKGIQCLLXGE

Use 'git update-ref' in post-commit example
...

> Now,
> brute-forcing 8 digits in the hash is one thing and doing it for all
> 40 is quite another, but I suspect that this demonstrates that it's
> *possible* to do it for a git hash, given enough computing resources.

SHA1 has always, by design, been vulnerable to a 2^80 resource attack :-).

Best,
Conrad
Received on Tue Jan 05 2021 - 00:25:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC