open security vulnerabilities on the latest fluent-bit version

[altafrattani]

There are several vulnerabilities, some over 10 years old, that are still present in the latest version. Do we have an ETA on when will these get resolved?

Here is the list

CVE-2010-0928 CVE-2011-3389 CVE-2013-4392 CVE-2015-3276 CVE-2017-14159 CVE-2017-17740 CVE-2018-20796 CVE-2018-5709 CVE-2018-6829 CVE-2020-13529 CVE-2020-15719 CVE-2021-33560 CVE-2022-1304 CVE-2022-41862 CVE-2022-4899

[patrick-stephens]

What OS/target are you looking at and with what tool?

If the CVEs are related to the OS supplied libraries that Fluent Bit depends on so the resolution would need to be provided by those upstream providers (if they deem it necessary to fix). If it is related to the vendored dependencies (see https://github.com/fluent/fluent-bit/tree/master/lib) then these can indeed be controlled by Fluent Bit and ETA will be greatly improved by submitting a PR to contribute the change.

What analysis have you done to confirm these are indeed relevant and impacting Fluent Bit? I am not trying to shift responsibility but focus the limited time and effort we have for open source maintenance on prioritising the most critical/exploitable CVEs for fix. Any analysis you can share will help speed things up.

I had a look at the first one initially to check and this is marked as won't fix by Red Hat for example (https://nvd.nist.gov/vuln/detail/CVE-2010-0928) plus seems to be referencing OpenSSL 0.9.8 - depending on the target we should be using either OpenSSL 1.x+ or 3.x+ (see https://github.com/fluent/fluent-bit/issues/7644 for work to step up) so it feels like this is a false positive or something dragged in by other dependencies. Again, likely target-specific but it's hard to say without those details.

[t0klian]

And CVE-2023-4911 as well. We need to wait for the next release to fix the vulnerabilities since the docker image is distroles and it requires additional effort to perform package upgrade on your own

[ira-gordin-sap]

I am not sure which Debian version is used here, because I see several in Dockerfile. https://security-tracker.debian.org/tracker/CVE-2022-1304 for example is fixed in Debian 12 (bookworm) so I suppose Debian 11 (bullseye) is used here. When do you plan to move Debian 12? (It will automatically fix CVE-2022-1304 and 14 more CVE's I see in fluent-bit version 2.1.10. Please let me know if it already fixed it in fluent-bit 2.2.0.)

[patrick-stephens]

Distroless images are used as the base image for the production image: https://docs.fluentbit.io/manual/installation/docker#why-use-distroless-containers

https://github.com/fluent/fluent-bit/blob/3ce15c6f68d40075acbaabb5941036f278091c4c/dockerfiles/Dockerfile#L155

The system dependencies are pulled at the time of image build (i.e. for the release) so it should pull any fixes from upstream repositories at that point. Each time a release is made it will get a snapshot of the system dependencies at that point - these are outside of Fluent Bit control.

As new CVEs are found and fixed all the time you should be stepping up to the latest release - backporting of fixes is not done for older releases for OSS versions. We do not overwrite images once released. Enterprise providers exist if you need this: https://fluentbit.io/enterprise/

Stepping up to Bookworm should just be a case of updating the Dockerfile (assuming there is a distroless version for it) so please submit a PR as contribution will always help speed it up. We may need to handle any dependency changes (e.g. a package may be renamed or extra packages are required or some can be removed).

We also have nightly builds if you want to verify if something is fixed in the next release: ghcr.io/fluent/fluent-bit/unstable:master.

Trivy is reporting no critical or high CVEs as part of the nightly build: https://github.com/fluent/fluent-bit/actions/runs/7284609185/job/19852008314

ghcr.io/fluent/fluent-bit/unstable:master (debian 11.8)
=======================================================
Total: 0 (HIGH: 0, CRITICAL: 0)

Note we ignore unfixed vulnerabilities here - there is nothing we can do for those as they must come from upstream.

These are the results I get with Grype at this specific point in time (i.e. the nightly build from yesterday and the current vulnerability database right now):

$ grype docker:ghcr.io/fluent/fluent-bit/unstable:master
 ✔ Vulnerability DB                [no update available]  
 ✔ Pulled image                    
 ✔ Loaded image                                                                                                                                                         ghcr.io/fluent/fluent-bit/unstable:master
 ✔ Parsed image                                                                                                                           sha256:51d271e7c5654999d60820334c1ac54c7f02be1387e16d7e55cf56c2973a5f7f
 ✔ Cataloged packages              [38 packages]  
 ✔ Scanned for vulnerabilities     [40 vulnerability matches]  
   ├── by severity: 1 critical, 4 high, 9 medium, 0 low, 26 negligible
   └── by status:   0 fixed, 40 not-fixed, 0 ignored 
NAME              INSTALLED                FIXED-IN     TYPE  VULNERABILITY     SEVERITY   
libatomic1        10.2.1-6                 (won't fix)  deb   CVE-2023-4039     Medium      
libc6             2.31-13+deb11u7          (won't fix)  deb   CVE-2023-4813     Medium      
libc6             2.31-13+deb11u7          (won't fix)  deb   CVE-2023-4806     Medium      
libc6             2.31-13+deb11u7                       deb   CVE-2019-9192     Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2019-1010025  Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2019-1010024  Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2019-1010023  Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2019-1010022  Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2018-20796    Negligible  
libc6             2.31-13+deb11u7                       deb   CVE-2010-4756     Negligible  
libcom-err2       1.46.2-2                 (won't fix)  deb   CVE-2022-1304     High        
libgcc-s1         10.2.1-6                 (won't fix)  deb   CVE-2023-4039     Medium      
libgcrypt20       1.8.7-6                  (won't fix)  deb   CVE-2021-33560    High        
libgcrypt20       1.8.7-6                               deb   CVE-2018-6829     Negligible  
libgnutls30       3.7.1-5+deb11u3          (won't fix)  deb   CVE-2023-5981     Medium      
libgnutls30       3.7.1-5+deb11u3                       deb   CVE-2011-3389     Negligible  
libgomp1          10.2.1-6                 (won't fix)  deb   CVE-2023-4039     Medium      
libgssapi-krb5-2  1.18.3-6+deb11u4                      deb   CVE-2018-5709     Negligible  
libk5crypto3      1.18.3-6+deb11u4                      deb   CVE-2018-5709     Negligible  
libkrb5-3         1.18.3-6+deb11u4                      deb   CVE-2018-5709     Negligible  
libkrb5support0   1.18.3-6+deb11u4                      deb   CVE-2018-5709     Negligible  
libldap-2.4-2     2.4.57+dfsg-3+deb11u1    (won't fix)  deb   CVE-2023-2953     High        
libldap-2.4-2     2.4.57+dfsg-3+deb11u1                 deb   CVE-2020-15719    Negligible  
libldap-2.4-2     2.4.57+dfsg-3+deb11u1                 deb   CVE-2017-17740    Negligible  
libldap-2.4-2     2.4.57+dfsg-3+deb11u1                 deb   CVE-2017-14159    Negligible  
libldap-2.4-2     2.4.57+dfsg-3+deb11u1                 deb   CVE-2015-3276     Negligible  
libssl1.1         1.1.1w-0+deb11u1         (won't fix)  deb   CVE-2023-5678     Medium      
libssl1.1         1.1.1w-0+deb11u1                      deb   CVE-2010-0928     Negligible  
libssl1.1         1.1.1w-0+deb11u1                      deb   CVE-2007-6755     Negligible  
libstdc++6        10.2.1-6                 (won't fix)  deb   CVE-2023-4039     Medium      
libsystemd0       252.5-2~bpo11+1                       deb   CVE-2023-31439    Negligible  
libsystemd0       252.5-2~bpo11+1                       deb   CVE-2023-31438    Negligible  
libsystemd0       252.5-2~bpo11+1                       deb   CVE-2023-31437    Negligible  
libsystemd0       252.5-2~bpo11+1                       deb   CVE-2020-13529    Negligible  
libsystemd0       252.5-2~bpo11+1                       deb   CVE-2013-4392     Negligible  
libzstd1          1.4.8+dfsg-2.1           (won't fix)  deb   CVE-2022-4899     High        
openssl           1.1.1w-0+deb11u1         (won't fix)  deb   CVE-2023-5678     Medium      
openssl           1.1.1w-0+deb11u1                      deb   CVE-2010-0928     Negligible  
openssl           1.1.1w-0+deb11u1                      deb   CVE-2007-6755     Negligible  
zlib1g            1:1.2.11.dfsg-2+deb11u2  (won't fix)  deb   CVE-2023-45853    Critical

As you can see, some are "won't fix" as well.

[patrick-stephens]

I will again implore folks to look at https://github.com/fluent/fluent-bit/issues/8117#issuecomment-1790395129.

Specifically the analysis aspect and any time you can contribute to help improve the overall product will benefit yourselves and the rest of the community.

[ira-gordin-sap]

@patrick-stephens Let's analyze the results you got with Grype at this specific point in time. Let's look on openssl lines: openssl 1.1.1w-0+deb11u1. If we go to https://tracker.debian.org/pkg/openssl, we can see the following:

oldstable: [1.1.1w-0+deb11u1](https://packages.debian.org/source/oldstable/openssl)
old-sec: [1.1.1n-0+deb11u5](https://packages.debian.org/source/oldstable-security/openssl)
stable: [3.0.11-1~deb12u2](https://packages.debian.org/source/stable/openssl)
stable-sec: [3.0.11-1~deb12u2](https://packages.debian.org/source/stable-security/openssl)

It means that the basic image is oldstable. Why? Can/should it be changed to stable-sec?

[patrick-stephens]

Sure, I suspect it is a hangover from the previous OpenSSL 1 usage which is still in place for older targets but there is an open issue on updating to OpenSSL 3 which should be supported now.

https://github.com/fluent/fluent-bit/blob/3ce15c6f68d40075acbaabb5941036f278091c4c/dockerfiles/Dockerfile#L111

The only problematic area might be transitive dependencies - if any of the other dependencies pull in OpenSSL 1.

So, feel free to submit a PR to update the container image to do so. This will be the quickest way to test and verify it plus get it into a release then.

Similar for any other dependencies there, if you think it needs updating please add it.

[ira-gordin-sap]

@patrick-stephens I think the problem here that the base image is bullseye (Debian 11) and not bookworm (Debian 12) - see in https://github.com/fluent/fluent-bit/blob/master/dockerfiles/Dockerfile#L108.

[vasuarv]

I have been working on this issue as well, and I have a patch for this, which moves the base image to bookworm (debian-12). The also causes an issue with the dependent projects like the grafana-labs fluent-bit plugin, which use the version 1.9.9 base image as well.

[patrick-stephens]

Do you have a PR @vasuarv ?

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days. Maintainers can add the exempt-stale label.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[vasuarv]

I thought I had posted the comment previously. The build from the main branch did not have this issue.

[patrick-stephens]

https://github.com/fluent/fluent-bit/pull/8916 should update the base image too