I decided to write this bit after I started participating on the Cert/CC Java Secure Coding guidelines and was looking at the rules in the Serialization section. I immediately spotted some problems and started working on how to do serialization right, in terms of security. I already knew many of the pitfalls, but I quickly found that secure validation while deserializing is extremely difficult. Need proof? If Joshua Bloch can't get it right, and the (Oracle/Sun) Secure Coding Guidelines can't get it right, and key core classes can't get it right, what chances do the rest of us have?
Java deserialization privilege escalation vulnerabilities keep popping up. I know of three that have been fixed, and it's a safe bet we haven't seen the last of them. But they've been discussed at length, so let's look at the rest of the problems in the world of Java serialization.
Early References - It is possible to create a cross reference scenario where any object controlled by the attacker gets a reference to another, sensitive object which is still being initialized. The attacker creates serialized data where an instance of the class SensitiveClass references an instance of EvilClass. EvilClass has a reference of that same SensitiveClass instance. Thus, when SensitiveClass is in the middle of being serialized, in order to deserialize it's fields, the EvilClass instance gets deserialized. If EvilClass has a readObject method, it gets control and a reference to the SensitiveClass which is still under construction.
Phantom Fields - Phantom Fields are an auxiliary technique to obtain early, incomplete references. A class such as integer does not have any object fields, so the early reference attack would not work by itself. But we can create n fields in the serialized data that don't exist in the actual classes. The values for these get read and then discarded, but if their values are objects controlled by the attacker, they can have a readObject method which gets executed before the other object has been fully initialized.
Phantom Superclasses - These work much like phantom fields, but with different timing. They are processed prior to the subclasses. This is significant because primitive fields are processed before object fields (in other words: superclass primitives, superclass objects, subclass primitives, subclass objects, ...) . So if, for example, one wishes to create a mutable java.lang.Integer, it is necessary to create a phantom superclass, which has a field containing a reference to the Integer being deserialized.
Repeated Fields - In the serialized data, a valid field for a class can be repeated any number of times. The values of this field are then written to the field repeatedly, even if the field is final (through the magic of java.misc.Unsafe). Attacker can achieve mutability (TOCTOU) for seemingly immutable classes (java.lang.Integer, etc).
Race conditions - ObjectInputStream and ObjectOutputStream are not internally synchronized and a lot of the de/serialization logic relies on fields of these two classes, which are shared between threads.
External call to defaultReadObject - As the attacker has a reference to the ObjectInputStream, he can call the defaultReadObject method on objects that do not wish to use default deserialization. Due to the race condition problems, it is possible to force a defaultReadObject before the class manages to call getFields.
External call to defaultWriteObject - Much like external call to defaultReadObject, leveraging the race condition, it is possible to call defaultWriteObject externally from another thread for any object that has a writeObject method.
Now let's break some stuff:
1) Example from Joshua Bloch's Effective Java (Item 76):
It shows an example of an immutable date range class, with validation in the readObject method.
001 package ser1;
002
003 import java.io.IOException;
004 import java.io.InvalidObjectException;
005 import java.io.ObjectInputStream;
006 import java.io.Serializable;
007 import java.util.Date;
008
009 // Immutable class that uses defensive copying
010 public final class Period implements Serializable {
011
012 private Date start;
013 private Date end;
014 /*
015 * @param start the beginning of the period
016 * @param end the end of the period; must not precede start
017 * @throws IllegalArgumentException if start is after end
018 * @throws NullPointerException if start or end is null
019 */
020 public Period(Date start, Date end) {
021 this.start = new Date(start.getTime());
022 this.end = new Date(end.getTime());
023 if (this.start.compareTo(this.end) > 0) throw new IllegalArgumentException(start + " after " + end);
024 }
025
026 public Date start () {
027 return new Date(start.getTime());
028 }
029
030 public Date end () {
031 return new Date(end.getTime());
032 }
033
034 public String toString() {
035 return start + " - " + end;
036 }
037
038 // readObject method with defensive copying and validity checking
039 private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
040 s.defaultReadObject();
041 // Defensively copy our mutable components
042 start = new Date(start.getTime());
043 end = new Date(end.getTime());
044 // Check that our invariants are satisfied
045 if (start.compareTo(end) > 0)
046 throw new InvalidObjectException(start + " after " + end);
047 }
048
049 // Remainder omitted
050 }
Broken. This can be circumvented in a rather controlled fashion, using cross referencing and a Date subclass (MutableDate). Imagine that the serialized data contains a Period Object whose start and end fields contain mutable Date subclasses which contain a reference back to the Period object. Deserialization executes the readObject method and calls MutableDate.getTime(). At this moment, MutableDate contains a reference to the PeriodObject before the defensive copying takes place.
2) Oracle Secure Coding guidelines (Guideline 5-4):
2a) Example 1
001 package ser2;
002
003 public final class SensitiveClass implements java.io.Serializable {
004
005 public SensitiveClass() {
006 // permission needed to instantiate SensitiveClass
007 securityManagerCheck();
008
009 // regular logic follows
010 }
011
012 // implement readObject to enforce checks during deserialization
013 private void readObject(java.io.ObjectInputStream in) {
014 // duplicate check from constructor
015 securityManagerCheck();
016
017 // regular logic follows
018 }
019
020 private void securityManagerCheck() {
021 // code omitted
022 }
023
024 }
025
Broken. It is possible to call ObjectInputStream.defaultReadObject from another thread before the securityManagerCheck takes place (or during it).
2b) Example 2
001 package ser3;
002
003 import java.io.IOException;
004
005 public final class SecureName implements java.io.Serializable {
006
007 // private internal state
008 private String name;
009
010 private static final String DEFAULT = "DEFAULT";
011
012 public SecureName() {
013 // initialize name to default value
014 name = DEFAULT;
015 }
016
017 // allow callers to modify private internal state
018 public void setName(String name) {
019 if (name != null ? name.equals(this.name) : (this.name == null)) {
020 // no change - do nothing
021 return;
022 } else {
023 // permission needed to modify name
024 securityManagerCheck();
025
026 inputValidation(name);
027
028 this.name = name;
029 }
030 }
031
032 // implement readObject to enforce checks during deserialization
033 private void readObject(java.io.ObjectInputStream in) throws ClassNotFoundException, IOException {
034 java.io.ObjectInputStream.GetField fields = in.readFields();
035 String name = (String) fields.get("name", DEFAULT);
036
037 // if the deserialized name does not match the default value normally
038 // created at construction time, duplicate checks
039
040 if (!DEFAULT.equals(name)) {
041 securityManagerCheck();
042 inputValidation(name);
043 }
044 this.name = name;
045 }
046
047 private void inputValidation(String name2) {
048 // code omitted
049 }
050
051 private void securityManagerCheck() {
052 // code omitted
053 }
054
055 }
Broken. It is possible to call ObjectInputStream.defaultReadObject from another thread before the readObject method invokes the .readFields() method.
2c) Example 3 - Secure writeObject implementation with a security check.
001 package ser4;
002
003 import java.io.IOException;
004
005 public final class SecureValue implements java.io.Serializable {
006
007 // sensitive internal state
008 private String value;
009
010 // public method to allow callers to retrieve internal state
011 public String getValue() {
012 // permission needed to get value
013 securityManagerCheck();
014 return value;
015 }
016
017 // implement writeObject to enforce checks during serialization
018 private void writeObject(java.io.ObjectOutputStream out) throws IOException {
019 // duplicate check from getValue()
020 securityManagerCheck();
021 out.writeObject(value);
022 }
023
024 private void securityManagerCheck() {
025 // code omitted
026 }
027 }
Broken. It is possible to call defaultWriteObject externally before the writeObject method calls securityManagerCheck (or during it).
3) java.lang.Integer
...
037 public final class Integer extends Number implements Comparable<Integer> {
...
628 /**
629 * The value of the <code>Integer</code>.
630 *
631 * @serial
632 */
633 private final int value;
...
1202 }
Broken. With a Phantom Superclass and Repeated fields it is possible to create a mutable Integer. An Integer which is zero and later on changes it's value to something else can be done in a controlled fashion. An Integer which keeps changing it's value in arbitrary manner can be timed.
4) java.io.File
...
120 public class File
121 implements Serializable, Comparable<File>
122 {
...
129 /**
130 * This abstract pathname's normalized pathname string. A normalized
131 * pathname string uses the default name-separator character and does not
132 * contain any duplicate or redundant separators.
133 *
134 * @serial
135 */
136 private String path;
...
1918 /**
1919 * readObject is called to restore this filename.
1920 * The original separator character is read. If it is different
1921 * than the separator character on this system, then the old separator
1922 * is replaced by the local separator.
1923 */
1924 private synchronized void readObject(java.io.ObjectInputStream s)
1925 throws IOException, ClassNotFoundException {
1926 ObjectInputStream.GetField fields = s.readFields();
1927 String pathField = (String)fields.get("path", null);
1928 char sep = s.readChar(); // read the previous separator char
1929 if (sep != separatorChar)
1930 pathField = pathField.replace(sep, separatorChar);
1931 this.path = fs.normalize(pathField);
1932 this.prefixLength = fs.prefixLength(this.path);
1933 }
1934
1935 /** use serialVersionUID from JDK 1.0.2 for interoperability */
1936 private static final long serialVersionUID = 301077366599181567L;
1937 }
Broken. It is possible to call ObjectInputStream.defaultReadObject externally along with a combination of phantom superclass and repeated field.
Conclusion
I'll put my code where my mouth is in future posts. The serialization framework is extremely complex and extremely powerful in that creates objects without calling constructors and sets values to fields that might be private and or final. This combination is a dangerous one for security.
