CVE scan lists high vulnerability against latest image k8s.gcr.io/nfd/node-feature-discovery:v0.11.1

[gseidlerhpe]

What happened:
CVE scan shows image uses lib/package with high vulnerability

What you expected to happen:
No critical or high vulnerability issues.

How to reproduce it (as minimally and precisely as possible):
docker scan k8s.gcr.io/nfd/node-feature-discovery:v0.11.1

Output shows:
✗ High severity vulnerability found in gcc-8/libstdc++6
Description: Information Exposure
Info: https://snyk.io/vuln/SNYK-DEBIAN10-GCC8-347558
Introduced through: gcc-8/[email protected], [email protected], meta-common-packages@meta
From: gcc-8/[email protected]
From: [email protected] > gcc-8/[email protected]
From: [email protected] > apt/[email protected] > gcc-8/[email protected]
and 2 more...

Organization: xxxxxxx
Package manager: deb
Project name: docker-image|k8s.gcr.io/nfd/node-feature-discovery
Docker image: k8s.gcr.io/nfd/node-feature-discovery:v0.11.1
Platform: linux/amd64
Base image: debian:10.12-slim
Licenses: enabled

Tested 85 dependencies for known issues, found 72 issues.

Your base image is out of date

1. Pull the latest version of your base image by running 'docker pull debian:10.12-slim'
2. Rebuild your local image

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

[zvonkok]

@marquiz ptal

[zvonkok]

/cc @ArangoGutierrez

[ArangoGutierrez]

This will require v0.11.2 since updating image hash at k8s.gcr.io/images doesn't allow hash updates

[marquiz]

I don't think this applicable to us. NFD binaries are statically linked golang binaries (no c compiler involved). The possible hooks run by nfd (worker) inside the image are deployed/managed by the sysadmin. Any thoughts?

[eero-t]

As that's not the minimal image, according to documentation it contains run-time support for Bash and Perl hooks: https://kubernetes-sigs.github.io/node-feature-discovery/v0.11/advanced/customization-guide.html#hooks

I.e. has several libs that may get out of date / require security updates.

(IMHO running random code for hooks is bad idea for several reasons, I'll expand on that in a separate ticket.)

[marquiz]

@gseidlerhpe v0.11.2 (#870) should fix this issue. Close?

[gseidlerhpe]

@marquiz unfortunately the v0.11.2 image still has critical and high vulnerabilities (mostly Debian and Go).

The basic docker scan (Snyk 1.827.0) lists 1 critical and 1 high:
✗ High severity vulnerability found in gcc-8/libstdc++6
Description: Information Exposure
Info: https://snyk.io/vuln/SNYK-DEBIAN10-GCC8-347558
Introduced through: gcc-8/[email protected], [email protected], meta-common-packages@meta
From: gcc-8/[email protected]
From: [email protected] > gcc-8/[email protected]
From: [email protected] > apt/[email protected] > gcc-8/[email protected]
and 2 more...

✗ Critical severity vulnerability found in zlib/zlib1g
Description: Out-of-bounds Write
Info: https://snyk.io/vuln/SNYK-DEBIAN10-ZLIB-2976149
Introduced through: meta-common-packages@meta
From: meta-common-packages@meta > zlib/zlib1g@1:1.2.11.dfsg-1+deb10u1

However, I also ran a more sensitive scan with Jfrog and that found many more: 10 critical, 28 high.

I've attached the full output in json format from both scans.
snyk-cve-scan-node-feature-discovery-v0.11.2.json.txt
jfrog-cve-scan-node-feature-discovery-v0.11.2.json.txt

Updating the base debian image should fix most if not all of the critical and high issues.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.