Serialization can be used maliciously, for example, to violate the intended invariants of a class. Deserialization is equivalent to object construction; consequently, all invariants enforced during object construction must also be enforced during deserialization. The default serialized form lacks any enforcement of class invariants; consequently, programs must not use the default serialized form for any class with implementation-defined invariants.
...
Validating deserialized objects establishes that the object state is within defined limits and ensures that all transient and static fields have secure values. However, fields that are declared final with a constant value will always be restored to the same constant value after deserialization. For example, the value of the field private transient final n = 42
after deserialization will be 42 after deserialization rather than 0. Deserialization produces default values for all other cases.
...
In this noncompliant code example [Bloch 2005], a class with singleton semantics uses the default serialized form, which fails to enforce any implementation-defined invariants. Consequently, malicious code can create a second instance even though the class should have only a single instance. For purposes of this example, we assume that the class contains only nonsensitive data.
Code Block | ||
---|---|---|
| ||
public class NumberData extends Number { // ...implement Implement abstract Number methods, like Number.doubleValue()... private static final NumberData INSTANCE = new NumberData (); public static NumberData getInstance() { return INSTANCE; } private NumberData() { // Perform security checks and parameter validation } protected int printData() { int data = 1000; // printPrint data return data; } } class Malicious { public static void main(String[] args) { NumberData sc = (NumberData) deepCopy(NumberData.getInstance()); // Prints false; indicates new instance System.out.println(sc == NumberData.getInstance()); System.out.println("Balance = " + sc.printData()); } // This method should not be used in production code public static Object deepCopy(Object obj) { try { ByteArrayOutputStream bos = new ByteArrayOutputStream(); new ObjectOutputStream(bos).writeObject(obj); ByteArrayInputStream bin = new ByteArrayInputStream(bos.toByteArray()); return new ObjectInputStream(bin).readObject(); } catch (Exception e) { throw new IllegalArgumentException(e); } } } |
...
More information on singleton classes is available in rule MSC07-J. Prevent multiple instantiations of singleton objects.
...
This noncompliant code example uses a custom-defined readObject()
method but fails to perform input validation after deserialization. The design of the system requires the maximum ticket number of any lottery ticket to be 20,000 , and the minimum ticket number be greater than 0. However, an attacker can manipulate the serialized array to generate a different number on deserialization. Such a number could be greater than 20,000 , or could be 0 or negative.
...
Any input validation performed in the constructors must also be implemented where ever wherever an object can be deserialized. This compliant solution performs field-by-field validation by reading all fields of the object using the readFields()
method and ObjectInputStream.GetField
constructor. The value for each field must be fully validated before it is assigned to the object under construction. For more complicated invariants, this validating before assignment may require reading multiple field values into local variables to enable checks that depend on combinations of field values.
...
Note that the class must be declared final to prevent a malicious subclass from carrying out a finalizer attack . (See rule see OBJ11-J. Be wary of letting constructors throw exceptions for more information about finalizer attacks). ) For extendable classes, an acceptable alternative is to use a flag that indicates whether the instance is safe for use. The flag can be set after validation and must be checked in every method before any operation is performed.
...
Note that this compliant solution is insufficient to protect sensitive data. See rule (see SER03-J. Do not serialize unencrypted , sensitive data for additional information).
Compliant Solution (Transient)
This compliant solution marks the fields as transient, so they are not serialized. The readObject()
method initializes them using the roll()
method. This class need not be final , as because its fields are private and cannot be tampered with by subclasses, and its methods have been declared final , to prevent subclasses from overriding and ignoring them.
Code Block | ||
---|---|---|
| ||
public class Lottery implements Serializable { private transient int ticket = 1; private transient SecureRandom draw = new SecureRandom(); public Lottery(int ticket) { this.ticket = (int) (Math.abs(ticket % 20000) + 1); } public final int getTicket() { return this.ticket; } public final int roll() { this.ticket = (int) ((Math.abs(draw.nextInt()) % 20000) + 1); return this.ticket; } public static void main(String[] args) { Lottery l = new Lottery(2); for (int i = 0; i < 10; i++) { l.roll(); System.out.println(l.getTicket()); } } private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { in.defaultReadObject(); this.draw = new SecureRandom(); roll(); } } |
Compliant Solution (
...
Nonserializable)
This compliant solution simply does not mark the Lottery
class serializable.:
Code Block | ||
---|---|---|
| ||
public final class Lottery { // ... } |
...
CVE-2012-0507 describes an exploit that managed to bypass Java's applet security sandbox and run malicious code on a remote user's machine. The exploit deserialized a malicious object that subverted Java's type system. The malicious object was an array of two objects. The second object was an AtomicReferenceArray<>
whose internal , of type AtomicReferenceArray<>
, contained an array, but this array was also the first object. This data structure could not be created without serialization because the array referenced by AtomicReferenceArray<>
should be private. However, while whereas the first object was an array of objects
of type Help
objects (which inherited from ClassLoader
), the AtomicReferenceArray<>
's internal array is an array of Object
. This meant that type was Object
, enabling the malicious code could to use AtomicReferenceArray.set(ClassLoader)
to create a an object that was subsequently interpreted as being of type Help
object . (Creation of class loaders with no cast necessary. A cast would have caught this type mismatch. This exploit allowed attackers to create their own ClassLoader
object, which is forbidden by the applet security manager.)
This exploit worked because, in Java versions prior to 1.7.0_02, the object of type AtomicReferenceArray<>
object performed no validation on its internal array.
...
This exploit was mitigated in Java 1.7.0_03 by having the the object of type AtomicReferenceArray<>
validate its array upon deserialization. The readObject()
method inspects the array contents, and if the array is of the wrong type, it copies makes a defensive copy of the array, foiling the exploit. This technique is recommended by OBJ06-J. Defensively copy mutable inputs and mutable internal components.
Code Block | ||||
---|---|---|---|---|
| ||||
public class AtomicReferenceArray<E> implements java.io.Serializable { private static final long serialVersionUID = -6209656149925076980L; // Rest of class... /** * Reconstitutes the instance from a stream (that is, deserializes it). * @param s the stream */ private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException { // Note: This must be changed if any additional fields are defined Object a = s.readFields().get("array", null); if (a == null || !a.getClass().isArray()) throw new java.io.InvalidObjectException("Not array type"); if (a.getClass() != Object[].class) a = Arrays.copyOf((Object[])a, Array.getLength(a), Object[].class); unsafe.putObjectVolatile(this, arrayFieldOffset, a); } } |
...
Using the default serialized form for any class with implementation-defined defined invariants may result in the malicious tampering of class invariants.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SER07-J |
Medium |
Probable |
High | P4 | L3 |
Automated Detection
Tool |
---|
Version | Checker | Description | |||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| JAVA.CLASS.SER.ND | Serialization Not Disabled (Java) |
Coverity | 7.5 | UNSAFE_DESERIALIZATION | Implemented | ||||||
Parasoft Jtest |
| CERT.SER07.RRSC | Define a "readResolve" method for all instances of Serializable types |
Related Guidelines
CWE-502, "Deserialization of Untrusted Data" | |
Guideline 8-3 / SERIAL-3 |
: View deserialization the same as object construction |
Bibliography
[API |
2014] |
Item 75, "Consider |
Using a Custom Serialized Form" |
2006] | Chapter 11, "Object Serialization |
" | |
Antipattern 8 |
, "Believing Deserialisation Is Unrelated to Construction" |
[Rapid7 2014] |
Metasploit: Java AtomicReferenceArray Type Violation Vulnerability |
...