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 via incorrect principal selection when using Kerberos Constrained Delegation result in unauthorized access to critical data or complete access to all GraalVM accessible data.

Remediation

Upgrade openjdk-jre to version 7.0.321, 8.0.311, 11.0.13, 17.0.1 or higher.

References

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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:

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

Overview

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

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

• Gentoo Security Advisory
• HP Security Bulletin
• Oracle Security Bulletin
• RHSA Security Advisory
• Security Focus

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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 due to improper access restriction of the MethodHandle.invokeBasic method of the Hotspot component.

Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service that supplies data to the APIs.

Remediation

Upgrade openjdk-jre to version 7.0.351, 8.0.342, 11.0.16, 17.0.4, 18.0.2 or higher.

References

• OpenJDK Security Advisory
• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Debian Security Tracker
• Oracle Security Advisory

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 due to a range check loop optimization issue in the hotspot/compiler component. An attacker can obtain sensitive information without authorization by exploiting the improper input validation.

Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, 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 8.0.401, 11.0.22, 17.0.10, 21.0.2 or higher.

References

• RedHat Bugzilla Bug
• Security Advisory
• Vulnerability Advisory

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 due to a flaw in the JVM class file verifier in the hotspot/runtime component. An attacker can execute unverified bytecode by crafting a malicious input that bypasses the verification process.

Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 8.0.401, 11.0.22, 17.0.10, 21.0.2 or higher.

References

• RedHat Bugzilla Bug
• Security Advisory
• Vulnerability Advisory

Overview

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

Affected versions of this package are vulnerable to Information Exposure in the core-libs/javax.script component.

Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 8.0.401, 11.0.22 or higher.

References

• Security Advisory
• Vulnerability Advisory

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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.

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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 Allocation of Resources Without Limits or Throttling the implementation of the IdentityHashMap class doesn't properly validate the value of its size attribute when creating object instances from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 Allocation of Resources Without Limits or Throttling. A flaw was found in the way the BMPImageReader class implementation in the ImageIO performs memory allocations when reading palette information from BMP images. A specially-crafted BMP file could cause a Java application to consume an excessive amount of memory when opened.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 Allocation of Resources Without Limits or Throttling. A flaw was found in the way the Attributes class in the Libraries component performs reading of attributes with very long values from the JAR file manifests. A specially-crafted JAR archive could cause a Java application reading its manifest to use an excessive amount of system resources and hang.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 Allocation of Resources Without Limits or Throttling when HttpServer has no connection count limit. Exploiting this vulnerability allows unauthenticated attackers with network access via HTTP protocol to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition.

Remediation

Upgrade openjdk-jre to version 8.0.351, 11.0.17, 17.0.5, 19.0.1 or higher.

References

• Oracle Security Alerts

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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) by allowing unauthenticated users with network access to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition via multiple protocols.

Note: This issue is reported to only affect Java running on Solaris platform and is not believed to be applicable to other platforms.

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.331, 8.0.321 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit
• Oracle Security Advisory
• RedHat Bugzilla Bug

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) by allowing unauthenticated attackers with network access via multiple protocols to compromise the application.
Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs through a web service that supplies data to the APIs.

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.341, 8.0.331, 11.0.15, 17.0.3, 18.0.1 or higher.

References

• Oracle Security Report
• RedHat Bugzilla Bug

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) due to the computeNextExponential method of the Libraries component failing to comply with the documentation, returning sometimes negative numbers.

Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service that supplies data to the APIs.

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.351, 8.0.342, 11.0.16, 17.0.4, 18.0.2 or higher.

References

• OpenJDK Security Advisory
• Oracle Security Advisory
• RedHat Bugzilla Bug

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) due to excessive memory allocation in X.509 certificate parsing (Security, 8286533). Exploiting this vulnerability allows unauthenticated attackers with network access via HTTPS to cause a partial denial of service of Oracle Java SE, Oracle GraalVM Enterprise Edition.

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 8.0.351, 11.0.17 or higher.

References

• Oracle Security Alerts

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.

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

• RedHat Bugzilla Bug

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 security-libs/javax.net.ssl, when running untrusted code.

Remediation

Upgrade openjdk-jre to version 8.0.391, 11.0.21, 17.0.9, 21.0.1 or higher.

References

• Vulnerability Advisory

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. It allows unauthenticated attacker with network access via TLS to compromise Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service.

Remediation

Upgrade openjdk-jre to version 7.0.321, 8.0.311, 11.0.13, 17.0.1 or higher.

References

• Oracle Critical Patch Update Advisory
• RedHat Bugzilla Bug

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 via the CORBA component.

Note: This is only exploitable if data is supplied to APIs without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service.

Remediation

Upgrade openjdk-jre to version 8.0.391 or higher.

References

• Vulnerability Advisory

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 StringBuffer and StringBuilder classes implementation in the Libraries component failed to properly validate the value of the count attribute during object deserialization. A specially-crafted input could cause a Java application to misbehave because of StringBuffer or StringBuilder object instances in an inconsistent state.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 ObjectInputStream class implementation in the Serialization component doesn't sufficiently validate data read from the input serialized stream when reading serialized exceptions. A specially-crafted serialized stream could use this flaw to bypass certain deserialization restrictions (defined via jdk.serialFilter system or security property).

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 by allowing unauthenticated malicious actors to update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs through a web service that supplies data to the APIs.

Remediation

Upgrade openjdk-jre to version 7.0.341, 8.0.331, 11.0.15, 17.0.3, 18.0.1 or higher.

References

• Oracle Security Report
• RedHat Bugzilla Bug

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

• Oracle Patch Notes
• RedHat Bugzilla Bug
• Upstream Commit

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 Infinite loop. A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component handles and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

Overview

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

Affected versions of this package are vulnerable to Information Exposure. TransformerImpl class implementation in the JAXP component did not properly check access restrictions when performing URI resolution. This could possibly lead to information disclosure when performing XSLT transformations.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

Overview

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

Affected versions of this package are vulnerable to Information Exposure. The XMLEntityManager class implementation in the JAXP component doesn't properly perform access checks. A Java application using a SAX XML parser in certain configurations could be tricked into disclosing information when parsing a specially-crafted XML file.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

Overview

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

Affected versions of this package are vulnerable to Information Exposure due to a class compilation issue in the Hotspot component.

Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service that supplies data to the APIs.

Remediation

Upgrade openjdk-jre to version 7.0.351, 8.0.342, 11.0.16, 17.0.4, 18.0.2 or higher.

References

• OpenJDK Security Advisory
• Oracle Security Advisory
• RedHat Bugzilla Bug

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 or Wraparound. A flaw was found in the BMPImageReader class implementation in the ImageIO component, which allows a specially-crafted BMP image to bypass previously applied protection and cause a Java application to allocate an excessive amount of memory when opened.

Note:

this is due to an incomplete fix for CVE-2021-35586.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 or Wraparound. A flaw was found in the way the Hotspot component of OpenJDK handled array indexes on 64-bit x86 platform. A large index could trigger a displacement overflow in LIRGenerator::emit_array_address, possibly leading to access at an invalid array position.

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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 Write. A flaw was found in the way the Hotspot component of OpenJDK processed classes with _fields that needed to be written to in Rewriter::scan_method().

Remediation

Upgrade openjdk-jre to version 7.0.331, 8.0.321, 11.0.14, 17.0.2 or higher.

References

• Oracle Security Alerts
• RedHat Bugzilla Bug

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.

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

• RedHat Bugzilla Bug

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 Unsafe Reflection via improper object-to-string conversion in AnnotationInvocationHandler.

Remediation

Upgrade openjdk-jre to version 7.0.341, 8.0.331, 11.0.15, 17.0.3, 18.0.1 or higher.

References

• Oracle Security Report
• RedHat Bugzilla Bug

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) due to a segmentation fault in the ciMethodBlocks::make_block_at() function. This allows attackers to cause a denial of service.

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 11.0.17, 13.0.13, 15.0.9, 17.0.5, 19.0.0 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit
• JDK Issue
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• RedHat Bugzilla Bug

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

• OpenJDK Security Advisory
• RedHat Bugzilla Bug

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 Insertion of Sensitive Information into Log File in the security-libs/javax.xml.crypto component. An attacker with local access could access private keys.

Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator).

Remediation

Upgrade openjdk-jre to version 8.0.401, 11.0.22, 17.0.10, 21.0.2 or higher.

References

• RedHat Bugzilla Bug
• Security Advisory
• Vulnerability Advisory

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug

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

• Oracle Security Advisory
• RedHat Bugzilla Bug