Openssl dependency security issue fix

[c0ldb00t3r]

I have created an image using jammy-tiny-stack. There are a lot of security issues poping up for OpenSSL.

Scanned using grype.

[sophiewigmore]

Hey @c0ldb00t3r, I've copied the response I have to a similar issue: #152

We are always automatically shipping the latest versions of packages that come out, so as long as our automation is working properly, we will ship the latest available packages. The latest stack should have the latest packages available for Jammy. Are you using the latest stack (https://github.com/paketo-buildpacks/jammy-tiny-stack/releases/tag/v0.2.28)?

For the stack CVEs, many scanners report false positives for CVEs, because the versions of packages we ship are OS-version specific. The best source of truth for stack-related CVEs is Ubuntu's database and see the affected package version for the OS version (in this case Jammy). Checking just a few of these CVEs against Ubuntu's DB, there are no fixes:

In the latest release of this stack, we ship Openssl 3.0.2-0ubuntu1.15

https://ubuntu.com/security/CVE-2022-2068 - fixed in Openssl 3.0.2-0ubuntu1.5 on Jammy
https://ubuntu.com/security/CVE-2022-1292 - fixed in Openssl 3.0.2-0ubuntu1.1 on Jammy
https://ubuntu.com/security/CVE-2023-5363 - fixed in Openssl 3.0.2-0ubuntu1.12 on Jammy

[sophiewigmore]

I am closing this out due to a lack of response, but feel free to reopen it if you have any more questions

[dpippenger]

@sophiewigmore Hopefully it's ok to include my feedback here, it's relevant to the original submitters defect and will hopefully explain what's going on here. The original submitter is using a fairly popular container inventory and scanning tool called Anchore which can be found here and here . The tools run as standalone go binaries and free so hopefully you will give them a try. There are also free to use github actions if you wished to integrate these into your build.

You are correct in stating these are false positives, but the reason they are happening can be avoided. During your minification process there are some necessary files in /var/lib/dpkg/info being removed that are necessary for tools to match up the binaries on disk to the package entries in /var/lib/dpkg/status.d. In this specific case we are missing...

/var/lib/dpkg/openssl.list
/var/lib/dpkg/openssl.md5sums

But this could just have easily been other binary assets like libc... anchore just happens to pay special attention to things like openssl and queries the binary directy for it's version if it can't match up a dpkg entry. This results in anchore detecting openssl twice... once as the package version and the other as what it thinks is a rogue openssl binary version 3.0.2. So when the vuln scanner is run it's detecting no vulns in the debian package, but a bunch in the binary that claims it's a vanilla 3.0.2.

$ syft paketobuildpacks/run-jammy-tiny:0.2.55
 ✔ Loaded image paketobuildpacks/run-jammy-tiny:0.2.55
 ✔ Parsed image sha256:4e0a81c97fdb84703bcc6ae32826bc1974479d47660f3b7b485c197497e9144d
 ✔ Cataloged contents
   ├── ✔ Packages                        [9 packages]
   └── ✔ Executables                     [283 executables]
NAME             VERSION                   TYPE
base-files       12ubuntu4.7               deb
ca-certificates  20240203~22.04.1          deb
libc6            2.35-0ubuntu3.8           deb
libssl3          3.0.2-0ubuntu1.18         deb
netbase          6.3                       deb
openssl          3.0.2                     binary
openssl          3.0.2-0ubuntu1.18         deb
tzdata           2024a-0ubuntu0.22.04.1    deb
zlib1g           1:1.2.11.dfsg-2ubuntu9.2  deb

You can see the extra openssl in that output identified as "binary" instead of a deb package.

Keeping the list and md5sum files for the installed packages while discarding other unnecessary files in the info directory adds about 300k of uncompressed data for the packages listed. This would allow for proper matching of all binaries to their package and reporting only the vendored version strings and avoid the false positives.

Would you be willing to include these files to improve compatibility with Anchore and likely other vulnerability/sbom scanning tools that rely on this data?

[dpippenger]

So I should have looked more carefully at your build process before thinking you were removing the list and md5sum file. I see that they are just never created due to the method used to extract the deb. It should be fairly trivial to generate these files from the deb that's already downloaded for install.

I'm sure you could work this out on your own, but since I'm asking it's only fair I provide an example of how this would be implemented. Here's an example Dockerfile that first breaks the openssl info, then regenerates it. If you comment out the bottom section and run syft you will see the duplicate openssl with the vanilla version. When uncommented the generated list and md5sums are sufficient to resolve it.

FROM ubuntu:jammy
RUN apt-get update && apt-get install openssl -y
RUN rm /var/lib/dpkg/info/openssl.*

#Uncomment below here to regenerate the info files and remove the duplicate openssl
RUN mkdir /tmp/foobar \
&&  apt download openssl \
&&  dpkg-deb -c openssl*.deb | awk '{print substr($6, 2)}' > /var/lib/dpkg/info/openssl.list \
&&  dpkg-deb -e openssl*.deb MD5SUMS \
&&  cp MD5SUMS/md5sums /var/lib/dpkg/info/openssl.md5sums

[kaovilai]

Thanks for the insight @dpippenger

Do you think they'll try to include this in the tiny run image? Or do you think we'll have to fork to have this.

[dpippenger]

I'm going to do my best to engage the maintainers about it. If they don't see this conversation because it's in a closed issue I'll open a new issue. I was just trying to avoid creating duplicate issues.

The maintainers of this project are meticulous about their builds and care a great deal about providing an accurate SBOM. But due to the nature of many of the builds layered on top of the base in this project it's not always going to be possible to make tools like syft/grype produce accurate data from the runtime image alone. They provide a means to get a "true" SBOM for these images by generating a supplemental SBOM file.

So I think it will be up to the maintainers to decide if the extra 300k to help runtime scanners avoid this false positive scenario is worthwhile given it doesn't fix every SBOM scenario for all of the uses of this base image. And users who want a true SBOM after layering applications would still need to solve for those additional layers.

[kaovilai]

Created github actions to run syft and grype but not able to reproduce there..
https://github.com/kaovilai/jammy-tiny-stack/actions/runs/11977936712/job/33396906384

[kaovilai]

Snyk works.

There is an issue opened here already for Grype which should solve this. anchore/grype#520