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

[Eli Schwartz]

On 07/02/2017 07:34 PM, Ismael Bouya wrote:
> (Sun, Jul 02, 2017 at 07:22:23PM -0400) Eli Schwartz via arch-general :
>> Okay, this I am genuinely curious about.
>>
>> In what circumstances can I have:
>> - the systemd repository cloned over the git:// protocol
>> - an annotated tag for systemd v233 signed by Lennart Poettering.
>> - an annotated tag for systemd v232 signed by Lennart Poettering.
>> - a man in the middle attack
>> - `git verify-tag --raw v233` reports a GOODSIG with a VALIDSIG
>>   ${fingerprint} that matches with Lennart's known GPG fingerprint as
>>   recorded in validpgpkeys
>>
>> And as a result, when I run the git command `git checkout
>> refs/tags/v233`, I am tricked into getting v232 instead which contains a
>> vulnerability.
> 
> Until there, it's exactly the topic of the presentation linked by
> Nicohood

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.

-- 
Eli Schwartz

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