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 togit 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. Usegit 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 inconfig.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 ascore.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-5Description: 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.