Waratek identifies two new deserialization vulnerabilities

Waratek contributes to the Oracle January 2018 CPU and to Java SE security

The first Oracle Critical Patch Update of 2018 contains fixes for 21 new vulnerabilities in the Java SE platform, 28.5 percent of which relate to deserialization flaws. As part of Waratek’s security research and analysis of the October 2017 Oracle CPU, two new deserialization vulnerabilities were identified in the Java platform that have been patched in the January 2018 CPU.

Background

In 2017 Oracle fixed a total of 79 vulnerabilities in the Java SE platform. More than 10% of these vulnerabilities were related to Serialization and RMI components.

Because of the growing risk of serialization issues in the JVM, Oracle introduced the JEP-290 Serialization Filtering mechanism on January 2017 in an attempt to mitigate deserialization vulnerabilities. The Serialization Filtering mechanism provides look-ahead capabilities in the stream that allows the filtering of allowed classes as well as the addition of specific restrictions and limits to the deserialized objects.

Depending on the nature of the serialization vulnerability, Oracle may either use the Serialization Filtering mechanism to patch the issue or fix the issue by adding hardcoded restrictions in the vulnerable components. For example, the October 2017 CPU contains four vulnerabilities related to serialization and it uses Serialization Filtering to patch two of them. The other two were patched using custom, hardcoded fixes.

The Serialization Filtering mechanism provides four different ways of limiting the byte stream to mitigate Denial-of-Service deserialization attacks. More specifically:

• maxdepth, sets the maximum depth of a graph
• maxrefs, sets the maximum number of internal references
• maxbytes, sets the maximum number of bytes in the input stream
• maxarray, sets the maximum array size allowed

The Issues

What is not clear from the feature’s documentation is that the maxarray stream limit is only applicable to serialized arrays contained in serialized objects.  Interestingly enough, the Serialization Filtering mechanism is unable to protect against the case where the array is created and initialized by the application using an array length that is read from the serialized byte stream.

For example, any component that contains a construct such as “new T[ois.readInt()]” is vulnerable to unbounded memory allocation and could lead to a Denial-of-Service attack of the JVM.

The task of eliminating these vulnerabilities requires the identification of every single method in the JRE that performs this instruction sequence. This is not always an easy task since the array length can be stored in any variable or be encapsulated in any object field making the detection of such cases very difficult to identify. This also the reason why the Serialization Filtering mechanism fails to protect these cases.

The JVM has no way to tell which bytes came from external byte streams and to trace them inside all the JVM operations. Therefore, if the deserialized array length is not properly restricted before it is passed into an array initialization, it is trivially easy to introduce a Denial-of-Service deserialization vulnerability.

Waratek researched the JRE codebase and has identified two new unbounded memory allocation vulnerabilities in two JRE subcomponents that may be remotely exploitable without authentication. More specifically, the vulnerable subcomponents are:

Note that applications do not have to use these components in order to be vulnerable to Denial-of-Service deserialization attacks. Any application that performs deserialization of untrusted data is vulnerable to the above mentioned DoS attacks.

Action Items

As discussed above, the Serialization Filtering mechanism is unable to provide protection for these cases and the JVM offers alternative to patch these vulnerabilities with no source code changes. On the other hand, Waratek’s virtual patching capabilities allows the patching of any JRE or application component without deploying any physical binaries or any source code changes.

Waratek customers should apply the virtual patches provided by Waratek to receive immediate protection without restarting their applications. Since January 2016, Waratek has protected customers from 116 recently discovered Java SE vulnerabilities and Zero Day attacks addressed in Oracle CPUs and other vendor patch updates using virtual patches and virtual Java upgrades.  These features eliminate the need to delay applying patches and routinely upgrading the Java platform.

Non-Waratek customers are highly recommended to apply the appropriate binary CPU as quickly as possible.

Risk Information

CVE ID: CVE-2018-2677
Waratek Advisory ID: WTK-2018-01
Bugtraq ID: 102656
Credit: Apostolos Giannakidis, Waratek Security Architect
CVSSv3 Base: 4.3
CVSSv3 Vector: AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L
Attack Vector: Network Attack
Complexity: Low
Risk Factor: Medium
Affected Products: Java SE: 6u171, 7u161, 8u152, 9.0.1; Java SE Embedded: 8u151

Additional References

http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
https://access.redhat.com/security/cve/cve-2018-2677
https://nvd.nist.gov/vuln/detail/CVE-2018-2677
https://www.securityfocus.com/bid/102656
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2677

Disclosure Timeline

2017-11-03 – Issues discovered
2017-11-06 – Issues and PoCs reported to vendor at [email protected]
2017-11-09 – Vendor starts investigating the issues and assigns the tracking number S0940139
2017-11-14 – Vendor agrees with our assessment and confirms the vulnerability
2017-12-24 – Vendor fixed the issue in main codeline
2018-01-12 – Vendor assigns CVE-2018-2677 to the vulnerability
2018-01-16 – Vendor posts advisory and releases the patch update

Oracle, Java, Java SE, Java Virtual Machine (JVM), and Java Runtime Environment (JRE) are all registered trademarks of Oracle.