Re: [PLUG] exploit breaks SHA-1

[brent timothy saner via plug <plug@lists.phillylinux.org>]

On 1/10/20 09:13, Rich Freeman wrote:
> On Fri, Jan 10, 2020 at 8:59 AM brent timothy saner via plug
> <plug@lists.phillylinux.org> wrote:
>>
>> - Git is not at risk, as SHA1 hashes are used to *identify* commits, not
>> *verify the integrity* of them. GPG sign-offs are used for the latter.
>>
> 
> While I realize Linus feels otherwise, this is incorrect.
> 
> GPG is used to verify the integrity of a commit record, but the commit
> record that is signed doesn't contain the actual source code (either
> the files or their revisions) - just metadata like
> date/author/description/etc.  The commit record references the actual
> source code via a tree reference, which is an SHA1 hash.
> 
> While technically you could argue that the SHA1 hash only "identifies"
> the source code, the fact is that it is the only thing linking the
> signature to the actual source code.
> 
> So, all you can be certain of in an SHA1-compromised world is that
> some person committed SOMETHING on a particular date, and that he gave
> it a particular description.  You can't know for sure WHAT they
> actually committed - only that it had a particular sha1 hash.  That
> would seem like a rather important detail.
> 
> That said, the git project apparently recognizes the problem (again,
> Linus's claims notwithstanding), and are working on fixes.  I have no
> idea how far along they are with it.
> https://github.com/git/git/blob/0ed8d8da374f648764758f13038ca93af87ab800/Documentation/technical/hash-function-transition.txt
> 
> Also, the practical utility of this attack might be mitigated by
> project workflows.  This isn't a preimage attack, so you need to stick
> some random-looking cruft in a file to play games with it.  That said,
> for some projects like hosting firmware blobs it might be easier to
> do.  For projects that scrutinize every line in every new commit it
> would be harder.
> 
> Footnote:  People might THINK that git stores a diff of what changed
> in the hash, because a diff is displayed when they use git show.  A
> git commit record doesn't contain any source code at all - any source
> that shows up in git show is auto-generated.  For example, here is an
> example of a signed commit record (generated with git show
> --pretty=raw).  The signature applies to basically the text of the
> proceeding record (with a little care you can copy/paste it into a
> text file in the right format, and command-line gpg will verify it):
> 
> commit c1ec1a88e4a3d657040fe9ca336f9a446a4059bf
> tree 3fbce6896d5f53e948b472c1013b704601705ba2
> parent 4cadbd9fb1d51e57a5b1fb141d9b9a6151ce01dc
> parent 26bf6dd6982f4a28a160af9749c6c5ee4269b120
> author Repository mirror & CI <repomirrorci@gentoo.org> 1578626739 +0000
> committer Repository mirror & CI <repomirrorci@gentoo.org> 1578626739 +0000
> gpgsig -----BEGIN PGP SIGNATURE-----
> 
>  iQEzBAABCAAdFiEE90jps8R+OTzCTI+vfCrAnNmPLt8FAl4X7rQACgkQfCrAnNmP
>  Lt8d0wf/ag/zeoOmLm/t7U4c+Ie97JGb639f5ds+oRyOykR/hHtYaPhCl95Cc5N9
>  EwisHhTLnEdh9beuvXRHS64VXnTb+LHn7BpYnlHIcCXhDEnw0rTCOUCT+qzj74TJ
>  K0q1iUQEKLIwKloCJfBPbe5lPPAtAwXXjiVHQXODU7DbEHzERE23TL5QKplOtSgC
>  /DOR2zdfF7M6+FTnmYRV869vEa5iDpPk0XCOVTcDECZx6sACK/6sxBGV5ZJ/0i7k
>  DN1lGxMvywQ3nx+iFcDLyyK8PQiqZa9KZX6Q+aPcAJj/6YVaFa+yOpJU6NasQZK6
>  LhZawV6yKTGLgNxGcovDw3iNjjDoEg==
>  =VjO3
>  -----END PGP SIGNATURE-----
> 
>     Merge updates from master
> 
> 
> 

yeah, rich, what do you think happens when other checkouts on other
machines do their next pull and the merge fails because the changes
recorded don't match the commit hash in the index? git's workflow itself
sort of tips off to tampering, no need for an extra workflow.

i stand by my case, though. commit hashes are used to identify commits.
your argument here is roughly like arguing that, say, GPS coords don't
represent where a house is located because they aren't a spatial mapping
of the house and its surroundings.

the original point was that commit hashes are unaffected by sha-mbles
because they are not used to *verify* the change. they *point* to it
(regardless of where the *actual changed data* lies). you are absolutely
going to notice if someone attempts some sort of sha-mbles-driven attack
on a git repository, because the index, change tracking, and working
tree state are going to be absolutely out of sync at that point, which
was my entire point, because it's not expected to match the actual data
(there is no verification done of the commit hash at any point, if
memory serves).

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug