Re: [PLUG] exploit breaks SHA-1

[Rich Freeman via plug <plug@lists.phillylinux.org>]

On Fri, Jan 10, 2020 at 9:43 AM brent timothy saner via plug
<plug@lists.phillylinux.org> wrote:
>
> yeah, rich, what do you think happens when

You don't need to take on a passive-aggressive tone.  This is just a discussion.

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

The changes WOULD match the commit hash in the index. That's the
point.  The previous commit wouldn't be modified at all.

The TREE would be modified, in such a way as to have the same hash.

However, in terms of workflow if you modified the top tree on a repo a
machine doing a pull wouldn't pull anything at all, because it
wouldn't even know anything changed.  Also, you probably couldn't push
the modifications to a typical server because again, you're trying to
push a commit it already thinks it has.

However, what you could do is set up your own little Linux repo and
say it is official and look it has Linus's signature on the top
commit, so it must be kosher.  Anybody cloning it would get a valid
signature from Linus, but modified source files.

> i stand by my case, though. commit hashes are used to identify commits.

Sure, they're used to identify commits.  They're also used to
associate commits with the actual CONTENT of the commit, because git
splits everything into a bazillion separate records.

> 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

The hashes will be identical, at least on the top of the repo.  An
existing clone will not pull the changes directly, because it won't
see any changes to pull.  Now, if somebody cloned the modified repo,
and made further changes, and then did another commit, and pushed that
to a master repo, then their changes would incorporate any changes
made by the attacker, and would now show up on the top commit, which
would then be pulled by other machines.  At that point lots of hashes
have changed - I'd have to think through what the receiving machine
would actually see, as anything that didn't have a changed hash would
reflect its old content and not the new content.  You could definitely
run into a situation where different clones end up with different
content depending on what they pulled when.

A git show would still show the sneaked-in changes in its diff, if you
looked at the right commit.

> (there is no verification done of the commit hash at any point, if
> memory serves).

Every object in git will still match its hash at all points in an
attack like this.  Gpg verification will verify that the commit record
itself (or tag record) wasn't modified, but that isn't the thing being
modified.

But, like I said, the git maintainers clearly recognize the issue here
which is why they're working on getting this into sha256.  And as I
said the impact is going to depend on workflow.  You can definitely
mess things up.  Actually completely sneaking things through depends a
lot on what gets looked at when, and who is cloning what.  Imagine
some repo that machines pull from nightly, and verify the top
signature.  Somebody manages to hack into the repo mirror and swap out
the repo with a tampered one, leaving the signature intact.  All your
machines that haven't syned the previous good repo since the last
commit will sync the new one, verify the signature, and then use the
tampered source code.

What this exploit does potentially allow is a repo where all the
hashes look good and a gpg signature verifies, and yet the source code
in that repo doesn't match what it was when the person doing the
signing actually signed it.  I think most people would consider that
to not be how the gpg signatures are supposed to work.  I mean, the
most important thing to protect with the signatures is the actual
source code, and that is the thing you can tamper with here.

-- 
Rich
___________________________________________________________________________
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