openjdk:8-jre: CRITICAL vulnerabilities found by Trivy

[hmarzooq]

Hi,

Trivy has reported below 5 CVE's as CRITICAL vulnerability on openjdk:8-jre

CVE-2021-2294, CVE-2019-8457, CVE-2022-27404, CVE-2022-1586, CVE-2022-1587. These all are from Debian side. And fortunately despite being marked as Critical, they're actually either false positive and/or categorised as Minor issue by Debian. But I've few queries here, and I would appreciate if I can get some clarification on these from openjdk:8-jre image maintainers:

1: What is the identified vulnerability is CRITICAL and is also not marked as Minor by Debian? In other words, if CVE really needs to be addressed, then what is policy from openjdk:8-jre side to get the fix from Debian? Is there a timeframe in which we can expect the fix to be reflected in openjdk:8-jre image?

2: Except CVE-2021-2294, all the remaining CVE's are shown fixed in bookworm, sid release of Debian. But I'm not able to find any openjdk-8 which is using base image from bookworm, sid release of Debian. Any advise on these lines ? As our application uses JDK8 and therefore we're bound to stick to JDK8 only. Therefore, what options we've from openjdk:8-jre image side when it comes to specific release of Debian?

Thank you!

[wglambert]

See https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images). In OpenJDK's case this has been in limbo because of https://github.com/docker-library/openjdk/issues/505. CVE severity may differ significantly in a containerized environment, many cve's including critical severity ones are sometimes not a significant vulnerability as they may rely on a specific component or vector of attack that isn't applicable in a containerized environment, like the examples in https://github.com/docker-library/openjdk/issues/449#issuecomment-763027011

Bookworm is unstable/testing, we only use stable releases of distributions https://www.debian.org/releases/

Right now OpenJDK has an update for openssl.

$ docker run -it --rm openjdk:8-jre bash
root@812d83d412b1:/# apt update && apt list --upgradable
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
Get:4 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [160 kB]
Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8182 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2592 B]
Fetched 8545 kB in 1s (6113 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
Listing... Done
libssl1.1/stable-security 1.1.1n-0+deb11u3 amd64 [upgradable from: 1.1.1n-0+deb11u2]
openssl/stable-security 1.1.1n-0+deb11u3 amd64 [upgradable from: 1.1.1n-0+deb11u2]

If you wanted to update these packages in the meantime you could make a derivative Dockerfile

docker build

```console $ docker build -t openjdk:8-jre - << EOF FROM openjdk:8-jre RUN apt-get update && apt-get install -y --no-install-recommends openssl libssl1.1 && rm -rf /var/lib/apt/lists/* EOF Sending build context to Docker daemon 2.048kB Step 1/2 : FROM openjdk:8-jre ---> d991802804b7 Step 2/2 : RUN apt-get update && apt-get install -y --no-install-recommends openssl libssl1.1 && rm -rf /var/lib/apt/lists/* ---> Running in 35d5af1c76f8 Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB] Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB] Get:4 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [160 kB] Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8182 kB] Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2592 B] Fetched 8545 kB in 1s (5975 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... The following packages will be upgraded: libssl1.1 openssl 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 2412 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://security.debian.org/debian-security bullseye-security/main amd64 libssl1.1 amd64 1.1.1n-0+deb11u3 [1559 kB] Get:2 http://security.debian.org/debian-security bullseye-security/main amd64 openssl amd64 1.1.1n-0+deb11u3 [853 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 2412 kB in 0s (83.6 MB/s) (Reading database ... 7891 files and directories currently installed.) Preparing to unpack .../libssl1.1_1.1.1n-0+deb11u3_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.1n-0+deb11u3) over (1.1.1n-0+deb11u2) ... Setting up libssl1.1:amd64 (1.1.1n-0+deb11u3) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype (Reading database ... 7891 files and directories currently installed.) Preparing to unpack .../openssl_1.1.1n-0+deb11u3_amd64.deb ... Unpacking openssl (1.1.1n-0+deb11u3) over (1.1.1n-0+deb11u2) ... Setting up openssl (1.1.1n-0+deb11u3) ... Processing triggers for libc-bin (2.31-13+deb11u3) ... Removing intermediate container 35d5af1c76f8 ---> 39fff94ca5ac Successfully built 39fff94ca5ac Successfully tagged openjdk:8-jre $ docker run -it --rm openjdk:8-jre bash root@3b636c6e88d3:/# apt update && apt list --upgradable Get:1 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] Get:2 http://deb.debian.org/debian bullseye InRelease [116 kB] Get:3 http://security.debian.org/debian-security bullseye-security/main amd64 Packages [160 kB] Get:4 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB] Get:5 http://deb.debian.org/debian bullseye/main amd64 Packages [8182 kB] Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [2592 B] Fetched 8545 kB in 2s (5388 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. Listing... Done ```

[hmarzooq]

Thanks, your response is quite comprehensive and understandable. Just a quick question as well: As you've referenced: #505 - then what alternative images you could refer instead of openjdk:8-jre? Since our application is bound to use JDK-8, therefore, I'm more concerned around this question.

[wglambert]

You could try Temurin or AdoptOpenJDK?

For the Tomcat image we went with Temurin https://github.com/docker-library/tomcat/pull/265

[tianon]

See also https://hub.docker.com/_/openjdk:

Some examples of other Official Image alternatives (listed in alphabetical order with no intentional or implied preference):

• amazoncorretto
• eclipse-temurin
• ibm-semeru-runtimes
• ibmjava
• sapmachine