BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News OpenJDK Docker Image Served Mis-Labeled Vulnerable JDK

OpenJDK Docker Image Served Mis-Labeled Vulnerable JDK

This item in japanese

Bookmarks

In May, the OpenJDK mailing list identified that the official Docker Image for OpenJDK contained a mis-attributed version number, indicating that the JRE contained security patches that were not actually present. The issue was resolved with cross-community collaboration between OpenJDK and Debian.

The designation of "official" is made by Docker and others, as the OpenJDK community did not create the image or produce the build. A full discussion on who created the build and what is meant by "official" and by whom is present within the image’s GitHub issue 320. The Docker image has been downloaded over ten million times.

The core issue relates to a development-level, time-of-check, time-of-use issue in the build. The build was produced on March 27, 2019, and labeled with version numbers (8u212 and 11.0.3) where security patches were not released until April 16, 2019. "The end result of these cumulative 'reasonable' (according to some people) choices is that the default openjdk runs done by millions of people on docker right now are using 'mystery meat', incomplete, and exposed builds while seeming to report (to the lay person) a Java version that would suggest a real 8u212 or 11.0.3," explains Gil Tene, CTO of Azul, who originally reported the issue on the OpenJDK mailing list. The term "mystery meat" refers to a labeled item of uncertain origin -- the term does not imply that the contents are not safe, just that they are unknown.

InfoQ discussed the issue with Martijn Verburg, CEO of jClarity and co-leader of the London JUG. The confusion derived from a recently introduced tag in the version control system, where the suffix "-ga" was added. This marker indicates to third parties, such as Debian’s volunteer maintainers, when builds should be made generally available. The marker is applied after an "embargo period" used by different JVM vendors to ensure that security updates can be distributed in a safe manner evenly amongst all. Without this coordination period, hackers regularly disassemble security patches to figure out where exploits were, then build exploit kits against versions that have not yet been patched. Debian, a project that provides over 51,000 Linux packages, cannot reasonably be involved in each project to understand versioning intricacies. This includes OpenJDK, where the "-ga" marker is new and previous versions of JDK 7 and 8 skipped numbers between releases.

The version number in the Docker image indicates that patches for CVE-2019-2602 and CVE-2019-2684  should have been included but were not. At least six security patches occurred between the time of release that should have been part of the Docker image. The version mis-match may cause downstream complexity with Software Composition Analysis tools, which analyze software for patches based on version. These tools assist organizations in identifying where they have outdated software with known CVEs so that they can patch or mitigate risk appropriately. Many of these tools will recognize the version number and incorrectly determine that these JREs are not vulnerable. The window of exposure will likely be short-lived, as many Java vendors release security patches on a quarterly basis. For example, Oracle’s next scheduled Critical Patch Update will occur on July 16, 2019. At that time, the current Java version number will be considered insecure as a new secure baseline takes its place.

Remediation work to patch the issue and prevent a recurrence was completed by Emanuel Bourg of the Apache Software Foundation.

Rate this Article

Adoption
Style

BT