Why there is no more "apt" command under /usr/bin in the version 4.0.0 ?

[renxunsaky]

I want to use apt command to remove the package libcurl3-gnutls to reduce the vulnerability of image, but this command can't be found anymore in the version 4.0.0. While it exists in the version 3.X

Thanks a lot

[thockin]

Don't we need that job for git to use HTTPS?

I changed the build process so the final result is about half the size (and less overall vulnerability surface). That included dumping apt.

Is there a specific CVE you are trying to mitigate?

[renxunsaky]

Don't we need that job for git to use HTTPS?

I changed the build process so the final result is about half the size (and less overall vulnerability surface). That included dumping apt.

Is there a specific CVE you are trying to mitigate?

Thanks for your quick reply. Yes, it's about this one: CVE-2023-23914 It seems that It's quite new.

[thockin]

If it is fixed in Debian, I can just cut a new release in a few days.

On Thu, Jul 20, 2023, 1:56 PM renxunsaky @.***> wrote:

Don't we need that job for git to use HTTPS?

I changed the build process so the final result is about half the size (and less overall vulnerability surface). That included dumping apt.

Is there a specific CVE you are trying to mitigate?

Thanks for your quick reply. Yes, it's about this one: CVE-2023-23914 https://github.com/advisories/GHSA-75qm-2q4j-qx6g It seems that It's quite new.

— Reply to this email directly, view it on GitHub https://github.com/kubernetes/git-sync/issues/773#issuecomment-1644593841, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVAUNLIWJWUIQDJFPWTXRGLOHANCNFSM6AAAAAA2R6Q3MY . You are receiving this because you commented.Message ID: @.***>

[renxunsaky]

If it is fixed in Debian, I can just cut a new release in a few days. …

Great ! I will wait for your new release :)

[renxunsaky]

Hi @thockin,

may I know when could you make a new release to fix this vulnerability ? It could be done this week ?

thanks a lot

[thockin]

The good news is that v4 doesn't have curl installed, so this is not an issue!

[renxunsaky]

No, the Vul. I indicated is from the library libcurl3-gnutls which is a dependency of git

[thockin]

https://security-tracker.debian.org/tracker/CVE-2023-23914

Ahh, that is a source package, which includes the library package as a result.

I was worried because trivy does not flag it, but it is fixed already:

$ docker run -ti --entrypoint "" gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc3 cat /var/lib/dpkg/status.d/libcurl3-gnutls | head
Package: libcurl3-gnutls
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 819
Maintainer: Alessandro Ghedini <ghedo@debian.org>
Architecture: amd64
Multi-Arch: same
Source: curl
Version: 7.88.1-10

[thockin]

Hmm, trivy does NOT flag rc1, though:

$ docker run -ti --entrypoint "" gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1 cat /var/lib/dpkg/status.d/libcurl3-gnutls | head
Unable to find image 'gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1' locally
v4.0.0-rc1: Pulling from k8s-staging-git-sync/git-sync
Digest: sha256:7403b7e796f36d75aeb7754eedb1a68863d35aa6a6bde2b8ac2d805111d1c715
Status: Downloaded newer image for gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1
Package: libcurl3-gnutls
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 736
Maintainer: Alessandro Ghedini <ghedo@debian.org>
Architecture: amd64
Multi-Arch: same
Source: curl
Version: 7.74.0-1.3+deb11u7

$ trivy image --ignore-unfixed gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1
2023-07-25T10:07:55.486-0700    INFO    Vulnerability scanning is enabled
2023-07-25T10:07:55.486-0700    INFO    Secret scanning is enabled
2023-07-25T10:07:55.486-0700    INFO    If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-07-25T10:07:55.486-0700    INFO    Please see also https://aquasecurity.github.io/trivy/dev/docs/scanner/secret/#recommendation for faster secret detection
2023-07-25T10:07:55.494-0700    INFO    Detected OS: debian
2023-07-25T10:07:55.494-0700    INFO    Detecting Debian vulnerabilities...
2023-07-25T10:07:55.503-0700    INFO    Number of language-specific files: 1
2023-07-25T10:07:55.503-0700    INFO    Detecting gobinary vulnerabilities...

gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1 (debian 11.7)
=============================================================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

[renxunsaky]

Hi @thockin,

Thanks for checking. I am agree with you that the vulnerability is only exposed when the package "curl" is installed (if I understand well). Here in the version 4.X, we don't have "curl" installed anymore.

But in your last command: trivy image --ignore-unfixed gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc1 The option "--ignore-unfixed" is to display only fixed vulnerabilities. It means that it's not fixed in the version rc1 if I am correct.

Indeed, according to https://security-tracker.debian.org/tracker/CVE-2023-23914 it's already fixed in the version "7.88.1-10" which is the case for rc3. But why Tryvy is still reporting it ? Because its DB is not updated ?

[thockin]

As I understand trivy, the --ignore-unfixed flag is to skip vulnerabilities that may be present in code, but that the distro has deemed to not be impacting their distribution.

[renxunsaky]

Hi @thockin,

Please allow me back to you for this issue.

After some analyse, I found that Trivy is always reporting the vulnerability even the image "git-sync:v4.0.0-rc3" has the version "7.88.1-10" installed for ibcurl3-gnutls, because Trivy thinks the OS version is bullseye. If it is bullseye, then it retrieves the "advisories" from the vulnerabilities source DB with two parameters: the os version(osVer) and the source package's name(pkg.SrcName).

And inside this DB, it's marked that the vulnerability is not fixed for the OS version 11 for the package curl. You could check the screenshot below and from the source code of Trivy: https://github.com/aquasecurity/trivy/blob/v0.43.1/pkg/detector/ospkg/debian/debian.go#L95

I see that in the version rc3, you're using the base image 12 (debian-base:bookworm-v1.0.0) https://github.com/kubernetes/git-sync/blob/v4.0.0-rc3/Makefile#L48

But, if we check the content of the file "/etc/debian_version", we can see, in fact, it's 11.7. That's why Trivy is reporting the vulnerability.

docker run -ti --entrypoint "" gcr.io/k8s-staging-git-sync/git-sync:v4.0.0-rc3 cat /etc/debian_version
11.7

However, if we run the following command, the base image is indeed with the version 12. Why the debian version is changed after the build ? Could you double check please ?

docker run -ti --entrypoint "" registry.k8s.io/build-image/debian-base:bookworm-v1.0.0 cat /etc/debian_version
12.0

[thockin]

Ooh, good catch. #780

[renxunsaky]

Oh, I think it's from this line: https://github.com/kubernetes/git-sync/blob/v4.0.0-rc3/Dockerfile.in#L107C13-L107C25

You copied everything (root directory "/") from the intermediate image which is debian 11. It's definitely the root cause here.