Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.vote > #4478

Re: Security review of tag2upload [transfer.fsckObjects]

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Russ Allbery <rra@debian.org> writes:

>> Can this be substantiated?  Using SHA1CD in Git does not necessarily
>> mean someone cannot manually create a Git repository with a colliding
>> git commit somewhere in the history that gets accepted by git, and
>> allows someone to replace actual file contents.  That may be the case,
>> but I haven't seen any detailed analysis answering that.
>
> This was a really interesting point that I didn't catch.  Thank you!  Let
> me try to rephrase this in the form of an attack and see if this captures
> what you were getting at.
>
> The attack: Using a pre-SHA-1DC version of Git, construct a benign and
> malicious pair of Git trees that diverge at some point by abusing the hash
> of an object vulnerable to SHAttered.

Right, and that this happened at some point in the past rather than on
the git tag commit id.  This git repository could be the upstream or the
debian git repository.

> Push the benign tree to Salsa, relying on Salsa not reverifying the
> hashes of new objects with a hardened hash, or alternately have
> already planted the benign tree in a Git repository imported into
> Salsa before SHA-1DC was in use.  Get that tree signed by a sponsor,
> again relying on the sponsor's git client not revalidating object
> hashes, and then follow the same attack pattern in either "Moving the
> tag" or "Replacing the upstream tree."  Rely on the tag2upload server
> not reverifying the hashes of the Git tree when it pulls it to
> construct the signed source package.
>
> In essence, this attack exploits the fact that Git is lazy about
> performing hashes and usually only does so when it has to.  I'm not sure
> this assumption is correct for Salsa in particular, but it's at least
> plausible.  The trees used in this attack would fail git fsck, because the
> critical object would hash to a different value using SHA-1DC than it does
> with SHA-1, but it's not clear that git fsck is called at any of the
> points that would detect this attack.
>
> I believe this attack would be prevented by setting transfer.fsckObjects
> to true in the Git configuration of the tag2upload worker and failing the
> operation if it detects anything.  (Or, equivalently, calling git fsck
> after git clone and failing on any detected problems.)  I believe this
> forces recomputation of the hashes of all received objects.  The object
> used in this attack would fail that hash recomputation because the
> tag2upload server would use a version of Git that uses SHA-1DC.  The cost
> is a performance penalty on git clone, which would be trivial for most
> repositories but which might be noticable for particularly large Git
> trees.
>
> My personal opinion is that always setting transfer.fsckObjects to true is
> good practice anyway to catch more banal problems such as disk corruption
> and memory bit flips, so while I'm not sure I would bother just for this
> attack, it might be a good idea on general principles.

I have had that settings in my .gitconfig for several years, and the
number of git repositories that fail to clone with it is not negligible.
I encourage people to enable it and experiment for themselves.  Try
https://git.savannah.gnu.org/git/coreutils.git for example.  I hack
around it by adding a 'fclone' alias, and I still need to use it once in
a while.

[transfer]
	fsckObjects = true
[alias]
	fclone = clone -c "fetch.fsckObjects=false"

Maybe the number of repositories on Salsa with this problem is low, but
isn't the tag2upload design vulnerable to upstream git repositories
having this problem too?  In the part of tag2upload that re-generate the
*.orig.tar.gz file.  Maybe I'm missing how that is supposed to work,
relying on debian/watch does not strongly/uniquely identify a release
artifact.  Many distributions store SHA256 hashes of the expected
upstream release tarball, and this is a good practice that Debian
doesn't support to my knowledge.

/Simon

Back to linux.debian.vote | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-12 03:40 +0200
  Re: Security review of tag2upload Antoine Beaupré <anarcat@debian.org> - 2024-06-12 19:20 +0200
    Re: Security review of tag2upload Simon McVittie <smcv@debian.org> - 2024-06-12 20:00 +0200
      Re: Security review of tag2upload Sam Hartman <hartmans@debian.org> - 2024-06-12 21:50 +0200
    Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-12 20:30 +0200
  Re: Security review of tag2upload Simon Josefsson <simon@josefsson.org> - 2024-06-13 16:00 +0200
    Re: Security review of tag2upload Simon Richter <sjr@debian.org> - 2024-06-13 16:10 +0200
      Re: Security review of tag2upload Simon Josefsson <simon@josefsson.org> - 2024-06-13 17:00 +0200
    Re: Security review of tag2upload Marco d'Itri <md@Linux.IT> - 2024-06-13 18:40 +0200
      Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-13 20:00 +0200
        Re: Security review of tag2upload Sam Hartman <hartmans@debian.org> - 2024-06-13 23:00 +0200
          Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 18:40 +0200
            Re: Security review of tag2upload Sam Hartman <hartmans@debian.org> - 2024-06-16 23:30 +0200
              Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-24 20:30 +0200
    Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-13 21:00 +0200
      Re: Security review of tag2upload [transfer.fsckObjects] Simon Josefsson <simon@josefsson.org> - 2024-06-14 00:00 +0200
        Re: Security review of tag2upload [transfer.fsckObjects] Russ Allbery <rra@debian.org> - 2024-06-14 00:50 +0200
          Re: Security review of tag2upload [transfer.fsckObjects] Russ Allbery <rra@debian.org> - 2024-06-14 01:00 +0200
  Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-16 05:10 +0200
    Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 08:50 +0200
      Re: Security review of tag2upload Gunnar Wolf <gwolf@debian.org> - 2024-06-16 09:00 +0200
      Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-16 12:50 +0200
        Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 18:10 +0200
          Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-16 18:20 +0200
            Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 18:50 +0200
              Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-16 19:10 +0200
                Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 20:30 +0200
                Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-16 21:20 +0200
                Re: Security review of tag2upload Matthias Urlichs <matthias@urlichs.de> - 2024-06-16 22:00 +0200
                Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-16 22:10 +0200
                Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-17 06:40 +0200
                Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-17 07:30 +0200
                Re: Security review of tag2upload Scott Kitterman <debian@kitterman.com> - 2024-06-17 07:50 +0200
                Re: Security review of tag2upload Louis-Philippe Véronneau <pollo@debian.org> - 2024-06-17 07:50 +0200
                Re: Security review of tag2upload Louis-Philippe Véronneau <pollo@debian.org> - 2024-06-17 08:20 +0200
                Re: Security review of tag2upload Jonas Smedegaard <jonas@jones.dk> - 2024-06-17 08:20 +0200
                Re: Security review of tag2upload Matthias Urlichs <matthias@urlichs.de> - 2024-06-17 09:40 +0200
                Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-17 17:40 +0200
                Re: Security review of tag2upload Aigars Mahinovs <aigarius@debian.org> - 2024-06-17 12:50 +0200
              Re: Security review of tag2upload Simon Josefsson <simon@josefsson.org> - 2024-06-17 11:00 +0200
                Re: Security review of tag2upload Brian May <bam@debian.org> - 2024-06-17 12:40 +0200
                Re: Security review of tag2upload Simon Josefsson <simon@josefsson.org> - 2024-06-17 13:30 +0200
                Re: Security review of tag2upload Matthias Urlichs <matthias@urlichs.de> - 2024-06-17 13:30 +0200
                Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-17 17:30 +0200
              Re: Security review of tag2upload Ian Jackson <ijackson@chiark.greenend.org.uk> - 2024-06-17 13:40 +0200
            Re: Security review of tag2upload Stefano Rivera <stefanor@debian.org> - 2024-06-16 19:30 +0200
          Re: Security review of tag2upload Ian Jackson <ijackson@chiark.greenend.org.uk> - 2024-06-17 13:30 +0200
  Re: Security review of tag2upload HW42 <hw42@ipsumj.de> - 2024-06-25 01:10 +0200
    Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-25 02:10 +0200
      Re: Security review of tag2upload Russ Allbery <rra@debian.org> - 2024-06-25 03:40 +0200
        Re: Security review of tag2upload Salvo Tomaselli <tiposchi@tiscali.it> - 2024-06-26 09:30 +0200
          Re: Security review of tag2upload Jonas Smedegaard <jonas@jones.dk> - 2024-06-26 09:50 +0200
            Re: Security review of tag2upload Salvo Tomaselli <tiposchi@tiscali.it> - 2024-06-26 10:40 +0200
              Re: Security review of tag2upload Jonas Smedegaard <jonas@jones.dk> - 2024-06-26 12:40 +0200
    Re: Security review of tag2upload Ian Jackson <ijackson@chiark.greenend.org.uk> - 2024-06-25 11:30 +0200
    Re: Security review of tag2upload Matthias Urlichs <matthias@urlichs.de> - 2024-06-25 12:10 +0200

csiph-web