Closed KYannick closed 3 years ago
TL;DR for Debian is that most/all k8s components switched to it because it is easier to manage, has more packages available, and doesn't use busybox (Google the legal history). At some point there were not cross-platform images, but that seems better now.
I also seem to recall an issue with the git version in Alpine, but we switched a while back.
Building fresh right now still shows 143 vulnerabilities, all of them from Debian.
@tallclair has historically been quite involved in this topic. It's not one that git-sync alone can decide.
Lots of discussion with folks who know this area better than me.
Some main points:
git
and ssh
and some other standard tools, so distroless is not an option.I know that the Debian team looks at vulnerability reports and fixes them when they are real.
Ergo, I must also believe that most of the listed vulnerabilities are not particularly relevant or are actually just bogus reports from tools.
I'm not super happy with that as the state of things (noise), but I don't think there's anything to do here right now.
I will look into how to better alert on REAL vulnerabilities.
So an important piece here is the --ignore-unfixed
option on Trivy. What most container scanning engines do by default is report issues that the debian/ubuntu projects have decided not to fix yet. This is in contrast to "traditional" scanning options like Nessus and Nexpose, which will , by default, not report the unfixed issues.
This leads to a very high level of reported issues in container VA. Whilst these are real CVEs, they tend to be less serious ones.
For most purposes, I generally recommend running with --ignore-unfixed
by default. For this image running with that option returns the below, which is rather easier to analyze.
Looking at that the vulnerable packages are apt
, libapt-pkg5.0
, libldap-2.4.2
and libldap-common
. Whether any of those are exploitable, would depend primarily on whether containers based on this image do LDAP operations, or possibly if they install packages via apt that come from untrusted sources.
Some more on this topic here
k8s.gcr.io/git-sync/git-sync:v3.2.2 (debian 10.7)
=================================================
Total: 24 (UNKNOWN: 0, LOW: 0, MEDIUM: 4, HIGH: 20, CRITICAL: 0)
+----------------+------------------+----------+-----------------------+-----------------------+---------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+----------------+------------------+----------+-----------------------+-----------------------+---------------------------------------+
| apt | CVE-2020-27350 | MEDIUM | 1.8.2 | 1.8.2.2 | APT had several integer |
| | | | | | overflows and underflows while |
| | | | | | parsing .deb packages, aka... |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-27350 |
+ +------------------+ + +-----------------------+---------------------------------------+
| | CVE-2020-3810 | | | 1.8.2.1 | Missing input validation in |
| | | | | | the ar/tar implementations of |
| | | | | | APT before version 2.1.2... |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-3810 |
+----------------+------------------+ + +-----------------------+---------------------------------------+
| libapt-pkg5.0 | CVE-2020-27350 | | | 1.8.2.2 | APT had several integer |
| | | | | | overflows and underflows while |
| | | | | | parsing .deb packages, aka... |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-27350 |
+ +------------------+ + +-----------------------+---------------------------------------+
| | CVE-2020-3810 | | | 1.8.2.1 | Missing input validation in |
| | | | | | the ar/tar implementations of |
| | | | | | APT before version 2.1.2... |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-3810 |
+----------------+------------------+----------+-----------------------+-----------------------+---------------------------------------+
| libldap-2.4-2 | CVE-2020-36221 | HIGH | 2.4.47+dfsg-3+deb10u4 | 2.4.47+dfsg-3+deb10u5 | openldap: Integer underflow |
| | | | | | in serialNumberAndIssuerCheck |
| | | | | | in schema_init.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36221 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36222 | | | | openldap: Assertion failure in |
| | | | | | slapd in the saslAuthzTo validation |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36222 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36223 | | | | openldap: Out-of-bounds |
| | | | | | read in Values Return Filter |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36223 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36224 | | | | openldap: Invalid pointer free |
| | | | | | in the saslAuthzTo processing |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36224 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36225 | | | | openldap: Double free in |
| | | | | | the saslAuthzTo processing |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36225 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36226 | | | | openldap: Denial of service |
| | | | | | via length miscalculation |
| | | | | | in slap_parse_user |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36226 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36227 | | | | openldap: Infinite loop in slapd with |
| | | | | | the cancel_extop Cancel operation |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36227 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36228 | | | | openldap: Integer underflow |
| | | | | | in issuerAndThisUpdateCheck |
| | | | | | in schema_init.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36228 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36229 | | | | openldap: Type confusion |
| | | | | | in ad_keystring in ad.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36229 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36230 | | | | openldap: Assertion failure in |
| | | | | | ber_next_element in decode.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36230 |
+----------------+------------------+ + + +---------------------------------------+
| libldap-common | CVE-2020-36221 | | | | openldap: Integer underflow |
| | | | | | in serialNumberAndIssuerCheck |
| | | | | | in schema_init.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36221 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36222 | | | | openldap: Assertion failure in |
| | | | | | slapd in the saslAuthzTo validation |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36222 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36223 | | | | openldap: Out-of-bounds |
| | | | | | read in Values Return Filter |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36223 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36224 | | | | openldap: Invalid pointer free |
| | | | | | in the saslAuthzTo processing |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36224 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36225 | | | | openldap: Double free in |
| | | | | | the saslAuthzTo processing |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36225 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36226 | | | | openldap: Denial of service |
| | | | | | via length miscalculation |
| | | | | | in slap_parse_user |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36226 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36227 | | | | openldap: Infinite loop in slapd with |
| | | | | | the cancel_extop Cancel operation |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36227 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36228 | | | | openldap: Integer underflow |
| | | | | | in issuerAndThisUpdateCheck |
| | | | | | in schema_init.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36228 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36229 | | | | openldap: Type confusion |
| | | | | | in ad_keystring in ad.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36229 |
+ +------------------+ + + +---------------------------------------+
| | CVE-2020-36230 | | | | openldap: Assertion failure in |
| | | | | | ber_next_element in decode.c |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-36230 |
+----------------+------------------+----------+-----------------------+-----------------------+---------------------------------------+
Also, run trivy with --ignore-unfixed
and it's a MUCH smaller list, none of which seem relevant.
Hi, I'm a maintainer of Trivy. I'm sorry to bother you with unfixed vulnerabilities😓 If you prefer to disable it by default, we can change the default behavior. We were actually talking about it in https://github.com/aquasecurity/trivy/issues/323 and it has been suspended. It might be a good time to discuss that again. I'd like to hear your vote.
@knqyf263 -- no worries! Liz is in the Kubernetes thread as well and she's already cross-linked that to the default behavior issue: https://github.com/aquasecurity/trivy/issues/323#issuecomment-778411413
Thanks! As I posted in the Kubernetes Slack, unfixed vulnerabilities are detected by default since developers might be able to workaround the vulnerability by changing the configuration, updating firewall settings, or something else without updating the version. It is especially useful when the vulnerability is critical and the patch is being delayed. In that case, the organization should manage to mitigate the vulnerability until the patch is released. But showing unfixed vulnerabilities might be great only for security-sensitive organizations. Most organizations may not want to see them. We can change the default behavior to suppress unfixed vulnerabilities. Also, please feel free to ask me if you have any other questions about the result.
Note: In addition to --ignore-unfixed
, you can define CVE-IDs to ignore via .trivyignore
and use OPA for applying Rego rules to detected vulnerabilities. You can accept the risk dynamically according to the package name, CVSS vector, CWE, etc.
https://github.com/aquasecurity/trivy#filter-the-vulnerabilities-by-open-policy-agent-policy
Thanks for all the quick responses! I will definetly look into the OPA features of trivy.
You can find more details here. https://static.sched.com/hosted_files/kccnceu20/e5/2020%3A08%20KubeCon%20Europe%202020.pdf
i create a an image from dockerfile before some days..at that time it was free from vulnerbilities but yesterday when i again scan that image it gives me 314 vulnerbilities of bebian(11.0) what is this issue please help me fast
Note: In addition to
--ignore-unfixed
, you can define CVE-IDs to ignore via.trivyignore
and use OPA for applying Rego rules to detected vulnerabilities. You can accept the risk dynamically according to the package name, CVSS vector, CWE, etc. https://github.com/aquasecurity/trivy#filter-the-vulnerabilities-by-open-policy-agent-policy
Is it right way to use --ignore-unfixed flag on live project
Also, run trivy with
--ignore-unfixed
and it's a MUCH smaller list, none of which seem relevant. Is it right to igonre those vulnerbilities
@goyalrohit850 Whether to use --ignore-unfixed
is kind of a risk decision a project/organization has to take.
In general these issues should be ones which the Debian projects has decided do not present (in the generic case) a significant vulnerability, which is why they are yet to release a fixed package.
The problem with reporting unfixed issues is that there is essentially no way to resolve them , without source compiling the affected packages with appropriate patches, which is often not something an individual organization would want to take on.
An additional strategy which can be used to mitigate this is to ensure that images have the smallest number of packages installed, to reduce the number of issues present and reported.
@raesene thanks for your response
Scanning the latest image with trivy reveals lots of vulnarabilities in the latest image.
A year ago a similar issue was raised for version 3.1.4 (https://github.com/kubernetes/git-sync/issues/229), then the solution was to update the base image to a newer version. At the moment the 'debian-base' image that is used again contains a lot of vulnarabilities. Why is this base image used? Could git-sync use alpine as base image, since these images contain far less vulnarabilities?