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, ConradReceived 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