Fix critical/high CVEs

[willholley]

The flux:1.12.3 image as published on Docker Hub is currently reporting vulnerable to the following CVEs:

Vulnerability ID	Severity	Affected Packages	How to Resolve
CVE-2019-5435	Low	libcurl	Upgrade libcurl to >= 7.64.0-r2
CVE-2019-5436	Low	libcurl	Upgrade libcurl to >= 7.64.0-r2
CVE-2019-5018	High	sqlite-libs	Upgrade sqlite-libs to >= 3.28.0-r0
CVE-2019-8457	Critical	sqlite-libs	Upgrade sqlite-libs to >= 3.28.0-r0

All issues have been addressed by the upstream packages that introduce them to the container and building the Dockerfile from source resolves the problem.

This is mostly a note to inform the changelog for the next release (assuming a patch release would be created rather than republishing under the existing tag).

[squaremo]

Thanks for bringing this up @willholley. Maybe we should have a vulnerabilities addressed section in the changelog -- something to consider.

[squaremo]

@willholley What did you use to do the scan?

[squaremo]

(cleared the milestone so that I can close it; but we can add this info to the changelog in retrospect)

[willholley]

@squaremo this was using the IBM Cloud Container Registry, which automatically applies a vulnerability scan. The latest image is currently reporting no issues:

Checking security issues for 'flux:1.13.0'...

Image 'flux:1.13.0' was last scanned on Thu Jun 13 12:02:39 UTC 2019
The scan results show that NO ISSUES were found for the image.

OK

[hiddeco]

@willholley thanks for the info!

We had a scan running when we were still using Quay.io (with a notification to the maintainers), but as we had to move away from Quay.io, this is no longer in place 😞

I will put some thought into an alternative solution.

[nabadger]

@hiddeco if it's of any use, the clair-scanner project is pretty useful for this

This project builds a daily DB of vulns, so you can do it all locally via CI.

• https://github.com/arminc/clair-local-scan
• https://github.com/optiopay/klar (a good scanner)

[ChipWolf]

@awh could the priority be bumped on this please?

[squaremo]

This would certainly be a useful part of the build. We don't have a prioritised list of issues to address, at present. @ChipWolf is there a specific CVE that you're hoping to see mitigated?

[geofffranks]

We're seeing a number of CVEs when scanning the latest image, all related to sqlite-libs + libcurl being out of date. Doesn't look like busybox 3.11 has newer versions of the packages available either.

CVE-2019-19646
CVE-2020-11656
CVE-2019-19317
CVE-2019-19959
CVE-2019-19926
CVE-2019-19923
CVE-2019-19880
CVE-2019-19603
CVE-2019-19925
CVE-2019-20218
CVE-2019-19924
CVE-2019-19645
CVE-2019-17595
CVE-2019-17594
CVE-2019-15601

Additionally, our scanner is flagging CIS_Docker_CE_v1.1.0 - 4.1 - image is built with to run as the root user, vs a less privileged user.

Any objections to a PR that would pull in the new libcurl/sqlite-libs from the edge repo, and set a non-root user for running flux? Are there any special privs flux needs if run as non-root?

[squaremo]

Any objections to a PR that would pull in the new libcurl/sqlite-libs from the edge repo

Nope! Super helpful, thank you.

and set a non-root user for running flux

This is not so easy because of various files having to get the right permissions when mounted (I am thinking of SSH config; may also apply to GPG things). It was attempted before -- quite a while ago -- and no doubt Kubernetes etc., have moved on since then.

[yebyen]

There are still high and medium (and low) severity reports described in #3077

From openssl/libcrypto1.1, openldap/libldap, musl/musl-utils, and curl/libcurl, according to snyk in docker scan

As of fluxcd/flux:1.21.0, which is the latest release at this time.

[kingdonb]

This issue appears to have been resolved by flux v1.21.1, which also closes #3077

I think the idea of adding vulnerabilities addressed to the changelog, I could make a list from snyk scan and add the dependency addressed as an additional task for closing #3400 if there's some value in it. I think #3371 must have been the change that solved it, (while #3371 is already briefly mentioned in the release notes, the CVEs it may have addressed are not.)

I don't know if any of these would have been remotely exploitable, maybe worth a mention. Should we put scans into the release process?

[kingdonb]

We can close this one now without any objections, as #3400 has closed too