Deserialization of untrusted data - Revision history

Pfirmst: /* References */ Update link

2017-06-22T01:12:07Z

‎References: Update link

Wichers: /* Examples */

2017-03-04T21:09:57Z

‎Examples

Pfirmst: /* Related Controls */

2017-01-18T00:06:10Z

‎Related Controls

Pfirmst: /* References */

2017-01-17T23:56:04Z

‎References

Pfirmst: /* References */

2016-08-18T04:03:13Z

‎References

Jmanico at 08:53, 29 June 2016

2016-06-29T08:53:21Z

Ledio5485: /* References */

2016-05-25T18:51:02Z

‎References

Dinis.cruz: Added link to 'Java Deserialization Vulnerabilities - The Forgotten Bug Class' to References

2016-05-02T11:57:47Z

Added link to 'Java Deserialization Vulnerabilities - The Forgotten Bug Class' to References

Pfirmst: /* Examples */

2016-01-31T11:36:19Z

‎Examples

Pfirmst: /* Related Controls */

2016-01-31T08:22:29Z

‎Related Controls

@@ Line 145: / Line 145: @@
 * [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0, a Java agent that protects applications from deserialization attacks]
 * [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]
-* [https://github.com/pfirmstone/JGDMS/tree/trunk/src/org/apache/river/api/io Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets]
+* [https://github.com/pfirmstone/JGDMS/wiki Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets] [[Category:Input Validation Vulnerability]]
 *[http://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10 Java Deserialization Vulnerabilities - The Forgotten Bug Class (RuhrSec Edition)]
 *[https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.]

@@ Line 98: / Line 98: @@
 A quote from ArrayList source (GPL2 license with classpath exception):
 <pre>
      /**
       * The maximum size of array to allocate.
@@ Line 114: / Line 113: @@
 Since Java's Serialization uses implicit construction, whereby the first non serializable no argument super class constructor is invoked to create a child class instance (along with some unsafe magic), it prevents classes from checking their invariant's until after construction has completed.  For this reason, the standard implicit java Serialization API is flawed from a security perspective.
-It is possible to create an ObjectInputStream that is backward compatible with current Serializable Object's serial form, for security, it requires a new deserialization API, the exclusion of circular references, limits placed on array lengths and the object cache, all while allowing classes to check their invariants prior to objects being created, such that no object can be created in an illegal state.  In addition administrators will need to be able to reduce the classes available for deserialization to only those required to limit the attack surface, similar to white-listing or using Permission's.
+It is possible to create an ObjectInputStream that is backward compatible with current Serializable Object's serial form, for security, it requires a new deserialization API, the exclusion of circular references, limits placed on array lengths and the object cache, all while allowing classes to check their invariants prior to objects being created, such that no object can be created in an illegal state.  In addition, administrators will need to be able to reduce the classes available for deserialization to only those required to limit the attack surface, similar to white-listing or using Permissions.
 ==Related [[Controls]]==

@@ Line 120: / Line 120: @@
 * Requirements specification: A deserialization library could be used which provides a cryptographic framework to seal serialized data.
 * Implementation: Use the signing features of a language to assure that deserialized data has not been tainted.
 * Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
 * Implementation: Explicitly define final [http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html readObject()] to prevent deserialization.
@@ Line 133: / Line 134: @@
 * Implementation: Make fields transient to protect them from deserialization.
-* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].
+* Implementation: In your code, override the [http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html ObjectInputStream#resolveClass()] method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in a library like [https://github.com/ikkisoft/SerialKiller SerialKiller].  Note that while this can prevent gadget attacks, it cannot prevent DOS, as there are vulnerabilities within ObjectInputStream that allow an attacker to use up all available memory.
-* Implementation: Use a safe replacement for the generic readObject() method as seen [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications here]. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.
+* Implementation: Use a safe replacement for the generic readObject() method as seen [http://www.contrastsecurity.com/security-influencers/java-serialization-vulnerability-threatens-millions-of-applications here]. Note that this addresses "billion laughs" type attacks by checking input length and number of objects deserialized.  Again this will not prevent DOS attacks on ObjectInputStream.
-* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0] and [https://github.com/kantega/notsoserial NotSoSerial]
+* Implementation: Use a Java agent to override the internals of ObjectInputStream to prevent exploitation of known dangerous types as seen in [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0] and [https://github.com/kantega/notsoserial NotSoSerial].  Keep in mind that whitelisting is safer than blacklisting.
 * Implementation: Participate in the reimplementation of ObjectInputStream; Atomic Serialization is designed with security in mind from the outset, while maintaining Object Serial Form compatibility; note this is not a drop in replacement like those above, but likely to be the most secure option.

@@ Line 145: / Line 145: @@
 * [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0, a Java agent that protects applications from deserialization attacks]
 * [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]
-* [https://github.com/pfirmstone/river-internet/tree/trunk/src/org/apache/river/api/io Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets]
+* [https://github.com/pfirmstone/JGDMS/tree/trunk/src/org/apache/river/api/io Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets]
 [[Category:Input Validation Vulnerability]]
 *[http://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10 Java Deserialization Vulnerabilities - The Forgotten Bug Class (RuhrSec Edition)]

@@ Line 145: / Line 145: @@
 * [https://github.com/Contrast-Security-OSS/contrast-rO0 rO0, a Java agent that protects applications from deserialization attacks]
 * [https://github.com/kantega/notsoserial NotSoSerial, a Java agent that protects applications from deserialization attacks]
-* [https://github.com/pfirmstone/river-internet/tree/Input-validation-for-Serialization/src/org/apache/river/api/io Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets]
+* [https://github.com/pfirmstone/river-internet/tree/trunk/src/org/apache/river/api/io Atomic Serialization using constructor with input validation, no circular references, Permission limited scope limited object cache and array length limits, with stream resets]
 [[Category:Input Validation Vulnerability]]
 *[http://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilitesruhrseceditionv10 Java Deserialization Vulnerabilities - The Forgotten Bug Class (RuhrSec Edition)]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
@@ Line 155: / Line 152: @@
 __NOTOC__
 [[Category:Vulnerability]]
 [[Category:Code Snippet]]
 [[Category:Java]]

@@ Line 95: / Line 95: @@
 Another example of a denial-of-service attack against any Java application that allows deserialization:
-By crafting a stream, such that it contains an ArrayList with a size of Integer.MAX_VALUE, even if all elements are null or the same object, an ArrayList of MAX_VALUE will be created, prior to deserialization of the elements.  Many collection classes and object arrays can be manipulated in this manner, as they create their capacity prior to reading in elements, few sanity checks are performed.
+By crafting a stream, such that it contains an ArrayList with a size of Integer.MAX_VALUE, even if all elements are null or the same object, an internal array of length MAX_VALUE will be created, on some JVM's this will cause an OutOfMemoryError prior to deserialization of the elements, this doesn't require much data in the inputStream.  Many collection classes and object arrays can be manipulated in similar wasy, as they create their capacity prior to reading in elements, few sanity checks are performed.
-Even if ObjectInputStream is overridden to perform look ahead deserialization with a white-list, ObjectInputStream itself, will allow an attacker to create a multidimensional array, with a size of Integer.MAX_VALUE and every array element it contains, to do the same, even if these arrays all contain the same object element reference, it will very quickly consume all available memory in the JVM.
+It's not like the JVM folks aren't aware, they're just hamstrung by backward compatibility with deployed code.
-Fortunately ObjectInputStream can be completely re-implemented and overridden by subclassing, in this case the entire functionality of ObjectInputStream has to also be re-implemented to read [https://docs.oracle.com/javase/7/docs/platform/serialization the Java serialization protocol].
+A quote from ArrayList source (GPL2 license with classpath exception):
 Since Java's Serialization uses implicit construction, whereby the first non serializable no argument super class constructor is invoked to create a child class instance (along with some unsafe magic), it prevents classes from checking their invariant's until after construction has completed.  For this reason, the standard implicit java Serialization API is flawed from a security perspective.