Docker azul/zulu-openjdk-alpine:8u192-8.33.0.1

Vulnerabilities

58 via 59 paths

Dependencies

14

Source

Group 6 Copy Created with Sketch. Docker

Target OS

alpine:3.8.1
Test your Docker Hub image against our market leading vulnerability database Sign up for free
Severity
  • 9
  • 28
  • 21
Status
  • 58
  • 0
  • 0
OS binaries
  • 1
  • 57

high severity

Out-of-bounds Write

  • Vulnerable module: musl/musl
  • Introduced through: musl/musl@1.1.19-r10 and musl/musl-utils@1.1.19-r10
  • Fixed in: 1.1.19-r11

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:8u192-8.33.0.1@* musl/musl@1.1.19-r10
  • Introduced through: azul/zulu-openjdk-alpine:8u192-8.33.0.1@* musl/musl-utils@1.1.19-r10

NVD Description

Note: Versions mentioned in the description apply to the upstream musl package. See Remediation section below for Alpine:3.8 relevant versions.

musl libc through 1.1.23 has an x87 floating-point stack adjustment imbalance, related to the math/i386/ directory. In some cases, use of this library could introduce out-of-bounds writes that are not present in an application's source code.

Remediation

Upgrade Alpine:3.8 musl to version 1.1.19-r11 or higher.

References

high severity

Buffer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Buffer Overflow. A flaw was found in the boundary checks in the java.nio buffer classes in the Libraries component of OpenJDK, where it is bypassed in certain cases. This flaw allows an untrusted Java application or applet o bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation in the way the readObject() method of the MethodType class in the Libraries component of OpenJDK checked argument types. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Improper Security Check

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Security Check in the TLS/SSL implementation in the JSSE component of OpenJDK, where it did not properly handle application data packets received before the handshake completion. This flaw allowed unauthorized injection of data at the beginning of a TLS session.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Modification of Assumed-Immutable Data (MAID)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Modification of Assumed-Immutable Data (MAID) via serialization filter changes via jdk.serialFilter property modification.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

high severity

NULL pointer dereference

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to NULL pointer dereference via the DrawGlyphList class in the 2D component in OpenJDK. A specially crafted font file could use this flaw to cause a Java application to crash.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

high severity
new

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Sandbox Bypass. A flaw was found in the way the Hotspot component of OpenJDK performed range check elimination. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 8.0.301, 11.0.12, 16.0.2 or higher.

References

high severity

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Sandbox Bypass. It was discovered that the boundary checks in the java.nio.Buffer class in the Libraries component of OpenJDK could have been bypassed when class instance was accessed concurrently. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

high severity

Sandbox Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Sandbox Bypass. A flaw was found in the way the imaging library in the 2D component of OpenJDK performed affine transformations of images. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Access Restriction Bypass. None

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Access Restriction Bypass. A flaw was found in the way the ForkJoinPool class in the Libraries component of OpenJDK handled its access control context. This could possibly lead to code being executed with incorrect permissions, possibly leading to bypass of certain intended restrictions defined by a SecurityManager.

Remediation

Upgrade openjdk-jre to version 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Command Injection

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_291

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Command Injection. It was discovered that the implementation of ProcessBuilder in the Libraries component of OpenJDK on the Windows platform did not properly detect command arguments that were not quoted correctly. This could lead to manipulation of command arguments when executing processes with arguments from untrusted sources.

Remediation

Upgrade openjdk-jre to version 16.0.1, 11.0.11, 8.0.291, 7.0.301 or higher.

References

medium severity

Cross-site Scripting (XSS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Cross-site Scripting (XSS). None

Details

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

Types of attacks

There are a few methods by which XSS can be manipulated:

Type Origin Description
Stored Server The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.
Reflected Server The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.
DOM-based Client The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.
Mutated The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

Affected environments

The following environments are susceptible to an XSS attack:

  • Web servers
  • Application servers
  • Web application environments

How to prevent

This section describes the top best practices designed to specifically protect your code:

  • Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
  • Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
  • Give users the option to disable client-side scripts.
  • Redirect invalid requests.
  • Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
  • Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
  • Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Cryptographic Issues

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Cryptographic Issues due to use of unsafe RSA-MD5 checkum in Kerberos TGS.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

Cryptographic Weakness

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_291

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Cryptographic Weakness. A flaw was found in the way the Libraries component of OpenJDK enforced constraints defined in the jdk.jar.disabledAlgorithms security property. Verification of a JAR file signed using a disabled algorithm could succeed in certain cases, leading to bypass of the intended security restrictions.

This vulnerability applies to Java deployments that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security.

Remediation

Upgrade openjdk-jre to version 16.0.1, 11.0.11, 8.0.291, 7.0.301 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS) in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Encoding Error

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Encoding Error. Incorrect isBuiltinStreamHandler causes URL normalization issues.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

HTTP Response Splitting

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to HTTP Response Splitting. The HttpServer implementation did not restrict the use of CR and LF characters in values for HTTP headers, possibly allowing HTTP response splitting attacks.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. None

Remediation

Upgrade openjdk-jre to version 7.0.241, 8.0.231, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Handling

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Handling via the HTTP proxy responses in HttpURLConnection.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Handling

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Handling. The Kerberos implementation in the Kerberos component in OpenJDK did not properly handle proxy credentials. This could lead to the unintended use of wrong credentials and possible user impersonation.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation. A flaw was found in the way the XMLSchemaValidator class in the JAXP component of OpenJDK enforced the "use-grammar-pool-only" feature. A specially-crafted XML file could possibly use this flaw to manipulate with the validation process in certain cases.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity
new

Improper Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Validation. A flaw was found in the way the FtpClient implementation in the Networking component of OpenJDK handled responses to the FTP PASV command. A malicious FTP server could cause a Java application using FtpClient to connect to a host and port that is not accessible from the FTP server and perform port scanning or banner extraction.

Remediation

Upgrade openjdk-jre to version 7.0.311, 8.0.301, 11.0.12, 16.0.2 or higher.

References

medium severity

integer overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to integer overflow via the SunGraphics2D class in the 2D component in OpenJDK. The check of offset and length values passed to drawChars() and drawBytes() methods could be bypassed, leading to excessive memory allocation or attempt to access buffer out of bounds.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Integer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Integer Overflow. It was discovered that the Hotspot component of OpenJDK did not properly check for integer overflows when when optimizing code, leading to out-of-bounds access. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

medium severity

Man-in-the-Middle (MitM)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Man-in-the-Middle (MitM). It does not correctly handle CertificateVerify TLS handshake message received unexpectedly. An attacker can use this flaw to affect confidentiality or integrity of a TLS connection.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

medium severity

Out-of-Bounds

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Out-of-Bounds. None

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_221

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). None

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.231, 8.0.221, 11.0.5, 13.0.1 or higher.

References

medium severity

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). The use of overly complex regular expressions in java.utils.Scanner could cause a high CPU usage when Scanner was used on parse certain inputs.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

medium severity
new

Signature Validation Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Signature Validation Bypass. A flaw was found in the way the Library component of OpenJDK handled JAR files containing multiple MANIFEST.MF files. Such JAR files could cause signature verification process to return an incorrect result, possibly allowing tampering with signed JAR files.

Remediation

Upgrade openjdk-jre to version 7.0.311, 8.0.301, 11.0.12, 16.0.2 or higher.

References

low severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Access Restriction Bypass due to an incomplete enforcement of maxDatagramSockets limit in DatagramChannelImpl.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

low severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). It was discovered that the implementation of the Proxy class in the Serialization component of OpenJDK could trigger an out-of-memory condition when deserializing Proxy class objects with many interfaces. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

low severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Denial of Service (DoS). A malicious X.509 certificate can trigger excessive memory usage in a Java application processing such a certificate.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

  • High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

  • Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

low severity

Deserialization of Untrusted Data

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Deserialization of Untrusted Data due to an Incorrect exception processing during deserialization in BeanContextSupport.

Details

Serialization is a process of converting an object into a sequence of bytes which can be persisted to a disk or database or can be sent through streams. The reverse process of creating object from sequence of bytes is called deserialization. Serialization is commonly used for communication (sharing objects between multiple hosts) and persistence (store the object state in a file or a database). It is an integral part of popular protocols like Remote Method Invocation (RMI), Java Management Extension (JMX), Java Messaging System (JMS), Action Message Format (AMF), Java Server Faces (JSF) ViewState, etc.

Deserialization of untrusted data (CWE-502), is when the application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, letting the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue intensified greatly in 2015, when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic and many other products.

An attacker just needs to identify a piece of software that has both a vulnerable class on its path, and performs deserialization on untrusted data. Then all they need to do is send the payload into the deserializer, getting the command executed.

Developers put too much trust in Java Object Serialization. Some even de-serialize objects pre-authentication. When deserializing an Object in Java you typically cast it to an expected type, and therefore Java's strict type system will ensure you only get valid object trees. Unfortunately, by the time the type checking happens, platform code has already created and executed significant logic. So, before the final type is checked a lot of code is executed from the readObject() methods of various objects, all of which is out of the developer's control. By combining the readObject() methods of various classes which are available on the classpath of the vulnerable application an attacker can execute functions (including calling Runtime.exec() to execute local OS commands).

  • Apache Blog

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

low severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. None

Remediation

Upgrade openjdk-jre to version 7.0.241, 8.0.231, 11.0.5, 13.0.1 or higher.

References

low severity

Improper Access Control

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Access Control. None

Remediation

Upgrade openjdk-jre to version 7.0.241, 8.0.231, 11.0.5, 13.0.1 or higher.

References

low severity

Improper Certificate Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Certificate Validation. A flaw was found in the way the Libraries component of OpenJDK handled blacklists of untrusted certificates. Alternate certificate encodings were not considered, causing certain certificate fingerprints to not be blacklisted, possibly leading to untrusted certificates being accepted.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

low severity

Improper Certificate Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Certificate Validation. A flaw was found in the way the JSSE component of OpenJDK performed TLS server name verification. The HostnameChecker class did not check if names stored in TLS server's X.509 certificate are in the normalized form, possibly leading to an incorrect name being matched.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation. It was discovered that the UnixUriUtils class in the Libraries component of OpenJDK did not properly check for invalid characters when performing URI to Path conversion. This could lead to creating Path objects with invalid paths.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

low severity

Improper Input Validation

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Improper Input Validation. The package conducts improper checks of SASL message properties in GssKrb5Base.

Remediation

Upgrade openjdk-jre to version 7.0.251, 8.0.241, 11.0.6, 13.0.2 or higher.

References

low severity

Information Disclosure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Disclosure. It was discovered that the LDAP client implementation in the JNDI component of OpenJDK did not properly track whether a connection to a server uses TLS encryption, and consequently did not properly restrict the set of authentication mechanisms that were allowed to be used over an unencrypted connection. This could possibly lead to sending of plain text authentication credentials over an unencrypted connection.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

low severity

Information Exposure

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Information Exposure. A flaw was found in the color management code in the 2D component of OpenJDK. A specially-crafted image file could cause a Java application to disclose portion of its memory.

Remediation

Upgrade openjdk-jre to version 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Insecure Permissions

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_271

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Insecure Permissions. It was discovered that the Libraries component of OpenJDK failed to perform permission check when converting file system paths to URI in UnixUriUtils and WindowsUriSupport classes. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Remediation

Upgrade openjdk-jre to version 7.0.281, 8.0.271, 11.0.9, 15.0.1 or higher.

References

low severity

Timing Attack

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Timing Attack. Timing attacks are possible in implementations of ECDSA/EdDSA in cryptographic software libraries which allows for practical recovery of the long-term private key. This is possible in implementations which leak the bit-length of the scalar during scalar multiplication on an elliptic curve. This leakage might seem minuscule as the bit-length presents a very small amount of information present in the scalar. However, in the case of ECDSA/EdDSA signature generation, the leaked bit-length of the random nonce is enough for full recovery of the private key used after observing a few hundreds to a few thousands of signatures on known messages, due to the application of lattice techniques.

Remediation

Upgrade openjdk-jre to version 8.0.232, 11.0.5 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception. It was discovered that the unmarshalKeyInfo() method of the DOMKeyInfoFactory class and the unmarshalXMLSignature() method of the DOMXMLSignatureFactory class could raise exceptions not declared as thrown by these methods when reading key info or XML signature data from XML input.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception. The invokeWriteObject() method of the ObjectStreamClass method failed to catch InstantiationError exception during object stream deserialization, which could cause an unexpected exception to be raised when processing an untrusted serialized input.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception in the Nashorn JavaScript engine in the Scripting component of OpenJDK. Processing of the forward references prior to checking for regular expression syntax errors could cause an unexpected exception to be raised when processing a specially crafted regular expression.

Remediation

Upgrade openjdk-jre to version 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception in the Nashorn JavaScript engine in the Scripting component of OpenJDK. The state machine of the regular expression Parser did not correctly handle empty string nodes in certain cases, which could cause an unexpected exception to be raised when processing a specially crafted regular expression.

Remediation

Upgrade openjdk-jre to version 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception. A reference to an uninitialized class descriptor encountered during object stream deserialization could cause an unexpected exception to be raised when processing an untrusted serialized input.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251, 11.0.7, 14.0.1 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception. A flaw was found in the DerInputStream class in the Libraries component of OpenJDK. A DER (Distinguished Encoding Rules) encoded input using indefinite length encoding not supported by the DerInputStream could cause it to raise an exception not declared to be thrown by the DerInputStream.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251 or higher.

References

low severity

Uncaught Exception

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.8.0_192-b01
  • Fixed in: 1.8.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@8u192-8.33.0.1 openjdk-jre@1.8.0_192-b01

Overview

openjdk-jre is a free and open-source implementation of the Java Platform, Standard Edition (Java SE).

Affected versions of this package are vulnerable to Uncaught Exception. A flaw was found in the DerValue class in the Libraries component of OpenJDK. An incorrect implementation of the DerValue.equals() method could cause the class to raise an exception not declared to be thrown by the DerValue.

Remediation

Upgrade openjdk-jre to version 7.0.261, 8.0.251 or higher.

References