Execution of untrusted code when cloning Git submodule (CVE-2024-32002)

[hannes-ucsc]

https://nvd.nist.gov/vuln/detail/CVE-2024-32002

From the inspector findings sheet:

https://docs.google.com/spreadsheets/d/1RWF7g5wRKWPGovLw4jpJGX_XMi8aWLXLOvvE5rxqgH8/edit#gid=1268375573

This repository uses easyrsa as a submodule. If an exploit was injected there, we would potentially execute malicious code during checkout on GitLab and locally.

Images currently affected are

• docker.io/gitlab/gitlab-runner/ubuntu-v16.11.1-linux-amd64
• docker.io/gitlab/gitlab-runner/ubuntu-v16.11.1-linux-arm64
• docker.io/library/python/3.11.9-bullseye-linux-amd64
• docker.io/library/python/3.11.9-bullseye-linux-arm64
• docker.io/ucscgi/azul-pycharm/2024.1.2-24-linux-amd64
• docker.io/ucscgi/azul-pycharm/2024.1.2-24-linux-arm64

The gitlab-runner images and python images are used pervasively, locally and on GitLab.

We don't use the azul-pycharm image in conjunction with cloning a repository or checking out submodules so the severity there is lower. The fix there could be to simply remove any git binaries from the image.

[hannes-ucsc]

The gitlab-runner image is based on Ubuntu and contains git 2.25.1

Ubuntu has already released a fix but GitLab hasn't incorporated that fix yet. Some image publishers periodically update their images with package updates, GitLab isn't one of them. We'd have to wait for the next version of the runner, assuming that when the corresponding image is created apt-get update && apt-get update will have been run in it. Alternatively, we could also harden the image ourselves, with the usual caveats of what a productivity killer that would be.

[hannes-ucsc]

The python image is based on Debian, uses Git 2.30.2 for which Debian has not yet released a fix.

The python image is not run directly. It is only used as the basis for the build image for GitLab. This image is built from scratch in every build using the Dockerfile in the root of the source tree. In the long run, we'd be better off switching to the -slim version of the python image and installing any missing packages from the Dockerfile. The -slim version doesn't have git and is therefore not affected by this vulnerability. It also has fewer vulnerabilities in general and is 85% smaller (screenshot of Dockerhub):

[hannes-ucsc]

For the pycharm image we should just remove git using the file list provided by by Docker Desktop:

[hannes-ucsc]

To summarize:

• [ ] ~Wait for a couple of weeks for the next gitlab-runner image to be released~
• [ ] Switch to the -slim version of the python image (borrow a sandbox and the corresponding GitLab instance to verify)
• [ ] Harden pycharm image by removing git (use act and Docker Desktop to verify that finding disappears)