Docker azul/zulu-openjdk-alpine:7u211-7.27.0.1

Vulnerabilities

68 via 82 paths

Dependencies

18

Source

Group 6 Copy Created with Sketch. Docker

Target OS

alpine:3.9.0
Test your Docker Hub image against our market leading vulnerability database Sign up for free
Severity
  • 13
  • 35
  • 20
Status
  • 68
  • 0
  • 0
OS binaries
  • 14
  • 54

high severity

Out-of-bounds Write

  • Vulnerable module: musl/musl
  • Introduced through: musl/musl@1.1.20-r3 and musl/musl-utils@1.1.20-r3
  • Fixed in: 1.1.20-r5

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* musl/musl@1.1.20-r3
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* musl/musl-utils@1.1.20-r3

NVD Description

Note: Versions mentioned in the description apply to the upstream musl package. See Remediation section below for Alpine:3.9 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.9 musl to version 1.1.20-r5 or higher.

References

high severity

Buffer Overflow

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

high severity

Cryptographic Issues

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1b-r1

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

ChaCha20-Poly1305 is an AEAD cipher, and requires a unique nonce input for every encryption operation. RFC 7539 specifies that the nonce value (IV) should be 96 bits (12 bytes). OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce. Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. Any OpenSSL internal use of this cipher, including in SSL/TLS, is safe because no such use sets such a long nonce value. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. OpenSSL versions 1.1.1 and 1.1.0 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1c (Affected 1.1.1-1.1.1b). Fixed in OpenSSL 1.1.0k (Affected 1.1.0-1.1.0j).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1b-r1 or higher.

References

high severity

Improper Certificate Validation

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1k-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1k-r0 or higher.

References

high severity

Integer Overflow or Wraparound

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1j-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1j-r0 or higher.

References

high severity

NULL Pointer Dereference

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1g-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

Server or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this issue. This issue did not affect OpenSSL versions prior to 1.1.1d. Fixed in OpenSSL 1.1.1g (Affected 1.1.1d-1.1.1f).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1g-r0 or higher.

References

medium severity

Out-of-bounds Write

  • Vulnerable module: musl/musl
  • Introduced through: musl/musl@1.1.20-r3 and musl/musl-utils@1.1.20-r3
  • Fixed in: 1.1.20-r6

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* musl/musl@1.1.20-r3
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* musl/musl-utils@1.1.20-r3

NVD Description

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

In musl libc through 1.2.1, wcsnrtombs mishandles particular combinations of destination buffer size and source character limit, as demonstrated by an invalid write access (buffer overflow).

Remediation

Upgrade Alpine:3.9 musl to version 1.1.20-r6 or higher.

References

medium severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

Command Injection

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_301

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

CVE-2014-2422

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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 CVE-2014-2422. It allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors.

Remediation

Upgrade openjdk-jre to version 7.0.55, 8.0.5 or higher.

References

medium severity

Denial of Service (DoS)

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_231

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

medium severity

Information Exposure

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1d-r2

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

There is an overflow bug in the x64_64 Montgomery squaring procedure used in exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH512 are considered just feasible. However, for an attack the target would have to re-use the DH512 private key, which is not recommended anyway. Also applications directly using the low level API BN_mod_exp may be affected if they use BN_FLG_CONSTTIME. Fixed in OpenSSL 1.1.1e (Affected 1.1.1-1.1.1d). Fixed in OpenSSL 1.0.2u (Affected 1.0.2-1.0.2t).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1d-r2 or higher.

References

medium severity

Integer Overflow or Wraparound

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1j-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1j-r0 or higher.

References

medium severity

Missing Encryption of Sensitive Data

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1d-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

Normally in OpenSSL EC groups always have a co-factor present and this is used in side channel resistant code paths. However, in some cases, it is possible to construct a group using explicit parameters (instead of using a named curve). In those cases it is possible that such a group does not have the cofactor present. This can occur even where all the parameters match a known named curve. If such a curve is used then OpenSSL falls back to non-side channel resistant code paths which may result in full key recovery during an ECDSA signature operation. In order to be vulnerable an attacker would have to have the ability to time the creation of a large number of signatures where explicit parameters with no co-factor present are in use by an application using libcrypto. For the avoidance of doubt libssl is not vulnerable because explicit parameters are never used. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1d-r0 or higher.

References

medium severity

NULL Pointer Dereference

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1k-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1k-r0 or higher.

References

medium severity

NULL Pointer Dereference

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1i-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1i-r0 or higher.

References

medium severity

Use of Insufficiently Random Values

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1d-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was intended to include protection in the event of a fork() system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case. A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced. If an application already calls OPENSSL_init_crypto() explicitly using OPENSSL_INIT_ATFORK then this problem does not occur at all. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1d-r0 or higher.

References

low severity

Access Restriction Bypass

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_241

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_251

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

Insecure Permissions

  • Vulnerable module: openjdk-jre
  • Introduced through: openjdk-jre@1.7.0_211-b10
  • Fixed in: 1.7.0_281

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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.7.0_211-b10
  • Fixed in: 1.7.0_261

Detailed paths

  • Introduced through: docker-image|azul/zulu-openjdk-alpine@7u211-7.27.0.1 openjdk-jre@1.7.0_211-b10

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

low severity

Inadequate Encryption Strength

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1j-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a server that is configured to support both SSLv2 and more recent SSL and TLS versions then a check is made for a version rollback attack when unpadding an RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are supposed to use a special form of padding. A server that supports greater than SSLv2 is supposed to reject connection attempts from a client where this special form of padding is present, because this indicates that a version rollback has occurred (i.e. both client and server support greater than SSLv2, and yet this is the version that is being requested). The implementation of this padding check inverted the logic so that the connection attempt is accepted if the padding is present, and rejected if it is absent. This means that such as server will accept a connection if a version rollback attack has occurred. Further the server will erroneously reject a connection if a normal SSLv2 connection attempt is made. Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this issue. In order to be vulnerable a 1.0.2 server must: 1) have configured SSLv2 support at compile time (this is off by default), 2) have configured SSLv2 support at runtime (this is off by default), 3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite list) OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to this issue. The underlying error is in the implementation of the RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING padding mode used by various other functions. Although 1.1.1 does not support SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the RSA_SSLV23_PADDING padding mode. Applications that directly call that function or use that padding mode will encounter this issue. However since there is no support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a security issue in that version. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.0.2y (Affected 1.0.2s-1.0.2x).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1j-r0 or higher.

References

low severity

Missing Encryption of Sensitive Data

  • Vulnerable module: openssl/libcrypto1.1
  • Introduced through: openssl/libcrypto1.1@1.1.1a-r1 and openssl/libssl1.1@1.1.1a-r1
  • Fixed in: 1.1.1d-r0

Detailed paths

  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libcrypto1.1@1.1.1a-r1
  • Introduced through: azul/zulu-openjdk-alpine:7u211-7.27.0.1@* openssl/libssl1.1@1.1.1a-r1

NVD Description

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

In situations where an attacker receives automated notification of the success or failure of a decryption attempt an attacker, after sending a very large number of messages to be decrypted, can recover a CMS/PKCS7 transported encryption key or decrypt any RSA encrypted message that was encrypted with the public RSA key, using a Bleichenbacher padding oracle attack. Applications are not affected if they use a certificate together with the private RSA key to the CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to decrypt. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).

Remediation

Upgrade Alpine:3.9 openssl to version 1.1.1d-r0 or higher.

References