kubernetes/git-sync

Remediate security vulnerabilities on 4.1.0

kingnarmer opened this issue · 5 comments

Was wondering if possible to remediate image 4.1.0 security vulnerabilities

trivy image --ignore-unfixed --severity HIGH,CRITICAL registry.k8s.io/git-sync/git-sync:v4.1.0 --scanners vuln

Total: 5 (HIGH: 4, CRITICAL: 1)

Scan results attached.
git-sync-scan.txt

I need to cut a 4.2.0 release anyway. :)

Thanks for quick response.

I pushed v4.2.0 to our harbor instance this morning.

In case it's helpful, these are the outstanding critical/high vulnerabilities -- some of the non-git issues are introduced by the base image (e.g the zlib1g vulnerability), and aren't really fixable. Upgrading git to 2.39.3, or higher should remediate the git vulnerabilities (but the debian git package 1:2.43.0 is still experimental)

CVE-2023-45853

Level: Critical
zlib1g
1:1.2.13.dfsg-1
Description: MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field.
NOTE: MiniZip is not a supported part of the zlib product.

CVE-2023-25652

Level: High
git 1:2.39.2-1.1
Description: Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, by feeding specially crafted input to git apply --reject, a path outside the working tree can be overwritten with partially controlled contents (corresponding to the rejected hunk(s) from the given patch).

A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid using git apply with --reject when applying patches from an untrusted source. Use git apply --stat to inspect a patch before applying; avoid applying one that create a conflict where a link corresponding to the *.rej file exists.

CVE-2023-29007

Level: High
git 1:2.39.2-1.1
Description: Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, a specially crafted .gitmodules file with submodule URLs that are longer than 1024 characters can used to exploit a bug in config.c::git_config_copy_or_rename_section_in_file(). This bug can be used to inject arbitrary configuration into a user's $GIT_DIR/config when attempting to remove the configuration section associated with that submodule. When the attacker injects configuration values which specify executables to run (such as core.pager, core.editor, core.sshCommand, etc.) this can lead to a remote code execution.

A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid running git submodule deinit on untrusted repositories or without prior inspection of any submodule sections in $GIT_DIR/config.

CVE-2023-2953

Level: High
libldap-2.5-0 2.5.13+dfsg-5

Description: A vulnerability was found in openldap. This security flaw causes a null pointer dereference in ber_memalloc_x() function.

CVE-2023-31484

Level: High
perl 5.36.0-7+deb12u1
Description: CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.

CVE-2023-51767

Level: High
openssh-client 1:9.2p1-2+deb12u2
Description: OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit.
NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges.

I pretty much depend on the base image to fix such CVEs. If Debian decides that (for example) https://security-tracker.debian.org/tracker/CVE-2023-29007 is a minor issue and doesn't provide a fix, I don't have a lot of good options. I can apply backports, but I don't want to just do that blindly,

When debian updates are available, I can quickly cut a new image.