[arch-general] git undetectable tag replacement? (Was: Sébastien Luttringer and Tobias Powalowski)

[Giovanni Santini]

Il 03/07/2017 04:14, Eli Schwartz via arch-general ha scritto:
> 
> So I was under the impression that git tags encode the tagname in the
> actual blob, and I didn't see how that attack (rooted in the basic
> nature of a branch as a lightweight, mutable, *pushable* pointer to a
> commit) was supposed to work unless of course it was talking about a
> lightweight tag (which is not really meant for public/permanent use)...
> 
> Having actually tested this out, I find myself quite bewildered.
> 
> Because, git *does* encode the tagname in the blob, like I thought.
> And... you *can* simply copy .git/refs/tags/tagname to create a fake
> tag, and then you see something quite bewildering:
> 
> ```
> [eschwartz at arch ~/git]$ git clone https://github.com/systemd/systemd
> [...]
> [eschwartz at arch ~/git]$ cd systemd
> [eschwartz at arch ~/git/systemd]$ echo "$(git show-ref -s v233)" >
> .git/refs/tags/v232
> [eschwartz at arch ~/git/systemd]$ git tag -v v232
> object d60c527009133a1ed3d69c14b8c837c790e78d10
> type commit
> tag v233
> tagger Lennart Poettering <lennart at poettering.net> 1488405946 +0100
> 
> systemd 233
> gpg: Signature made Wed 01 Mar 2017 05:05:46 PM EST
> gpg:                using RSA key B63B21879C3485B0
> gpg: Good signature from "Lennart Poettering <lennart at poettering.net>"
> [unknown]
> gpg:                 aka "Lennart Poettering <lennart at poettering.de>"
> [unknown]
> gpg:                 aka "Lennart Poettering (Red Hat)
> <lpoetter at redhat.com>" [unknown]
> gpg:                 aka "Lennart Poettering (Sourceforge.net)
> <poettering at users.sourceforge.net>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:          There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2  0DD6 327F 2695 1A01 5CC4
>      Subkey fingerprint: 16B1 C4EE C0BC 021A C777  F681 B63B 2187 9C34 85B0
> ```
> 
> I simply do not understand why git doesn't error when it sees that a tag
> ref named v232 points to a tag blob named v233. The information is all
> there, and it seems trivial to add a check.
> 
> Oh well, one more reason to use commit hashes rather than pkgver tags.
> (The other reason is, because upstreams themselves are quite capable of
> modifying tags and re-signing them without waiting for some attacker to
> play with the ref pointers.)
> 
> Anyway, I learned something today.
> 

I think I can reply to this. Just skip if not interesed to last part.

"""Thanks""" to a lab of a class I had the previous semester, I can
describe you exactly how Git blobs are... There are:
- normal *blob*s: standard files compressed using Deflate, have only a
small special header at the top
- *tree*s: a specially encoded file, pointing to blobs or other
*tree*s... call them *blobbed directories*
- *commits*: another deflated file, keeping the commit message and a
reference to a *tree*.
To be 100% I made one just now to check and I can say that we have
- *tags*: a plain file referring to a commit object

You see the point: you just renamed a text file pointing others. Unless
you change the commit binary file (doing this won't pass the gpg check)
or fake the whole .git blobs, it will point to the v233 commit and all
the stuff below it.
If you are instead saying that Git should notice that the file in the
refs folder is named improperly, just `man git` and see what *git* is :P :D

tl;dr: Too much an hassle; destroying a Git repo is easy, faking it is not.

P.S. Thanks to that class, we made some Java classes to handle Git
blobs, check them if you want: https://gitlab.com/ItachiSan/lab01/

-- 
Giovanni Santini
My blog: http://giovannisantini.tk
My code: https://git{hub,lab}.com/ItachiSan
My GPG: 2FADEBF5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170703/4c37cb55/attachment.asc>