Waratek Identifies Two New Deserialization Vulnerabilities
Waratek Identifies Two New Deserialization Vulnerabilities
Learn how these two vulnerabilities can cause issues with deserialization and Denial of Service attacks, and what's been done to remediate them.
Join the DZone community and get the full member experience.Join For Free
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.
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 in 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.
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 can be encapsulated in any object field, making the detection of such cases very difficult to identify. This is 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.
As discussed above, the Serialization Filtering mechanism is unable to provide protection for these cases and the JVM offers an alternative to patch these vulnerabilities with no source code changes. On the other hand, Waratek's virtual patching capabilities allow for 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.
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
Risk Factor: Medium
Affected Products: Java SE: 6u171, 7u161, 8u152, 9.0.1; Java SE Embedded: 8u151
2017-11-03 - Issues discovered.
2017-11-06 - Issues and PoCs reported to the vendor at email@example.com.
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 the main codeline.
2018-01-12 - Vendor assigns CVE-2018-2677 to the vulnerability.
2018-01-16 - Vendor posts advisory and releases the patch update.
Published at DZone with permission of James Lee , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.