There is 1 high vulnerability issue in image openjdk:8u322-slim

[Mango2020]

Image openjdk@sha256:aabce5cb670971a7c5d85e9e4ca9f3a955d7b6884449dca89fc0af602def946e found 1 high vulnerability. Would you please help fix it asap? Thanks.

Details above : High severity vulnerability found in gzip Description: An arbitrary file write vulnerability was found in GNU gzip's zgrep utility. When zgrep is applied on the attacker's chosen file name (for example, a crafted file name), this can overwrite an attacker's content to an arbitrary attacker-selected file. This flaw occurs due to insufficient validation when processing filenames with two or more newlines where selected content and the target file names are embedded in crafted multi-line file names. This flaw allows a remote, low privileged attacker to force zgrep to write arbitrary files on the system. Info: https://www.whitesourcesoftware.com/vulnerability-database/CVE-2022-1271 The gzip should be upgraded to gzip/stable-security 1.10-4+deb11u1.

[Mango2020]

[yosifkit]

The Debian update from earlier this week (https://github.com/docker-library/official-images/pull/12257) that caused a rebuild of the openjdk images barely missed including this update since it only became available on Debian stable today:

[2022-04-22] Accepted gzip 1.10-4+deb11u1 (source) into proposed-updates->stable-new, proposed-updates (Debian FTP Masters) (signed by: Milan Kupcevic) [2022-04-22] Accepted gzip 1.9-3+deb10u1 (source) into oldstable-proposed-updates->oldstable-new, oldstable-proposed-updates (Debian FTP Masters) (signed by: Milan Kupcevic)

- https://tracker.debian.org/pkg/gzip

(See https://security-tracker.debian.org/tracker/CVE-2022-1271 for which versions contain the fix)

I don't think this seems to be that exploitable since it requires the (java) application to run the zgrep utility on an attacker controlled filename and it would be very intense to rebuild all the images again right after finishing them.

Background:

Tags in the [official-images] library file[s] are only built through an update to that library file or as a result of its base image being updated (ie, an image FROM debian:buster would be rebuilt when debian:buster is built).

-https://github.com/docker-library/official-images/tree/2f086314307c04e1de77f0a515f20671e60d40bb#library-definition-files

Official Images FAQ:

Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame

- https://github.com/docker-library/faq/tree/6138d05aabf61563606d86f98d0ccbd99f162b33#why-does-my-security-scanner-show-that-an-image-has-cves

Since our build system makes heavy use of Docker build cache, just rebuilding the all of the Dockerfiles won't cause any change. So we rely on periodic base image updates.

We strive to publish updated images at least monthly for Debian and Ubuntu. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Alpine and Oracle Linux, and are subject to their own maintenance schedule.

- from the same FAQ link

In the meantime, users can apt-get update && apt-get upgrade -y && rm -rf /var/lib/apt/lists/* in a dependent image to get the fix earlier.

[tianon]

This will be fixed by https://github.com/docker-library/official-images/pull/12393 (which should be merged later today).