The serialization Serialization and deserialization features can be exploited to bypass security manager checks. A serializable class may employ contain security manager checks in its constructors for various reasons. For example, the checks prevent , including preventing untrusted code from modifying the internal state of the class. Security Such security manager checks must be replicated at all points where wherever a class instance can be constructed. Because deserialization acts like a constructor, all the relevant methods must contain a security check. If the For example, if a class enables a caller to retrieve sensitive internal state contingent upon security checks, the same those checks must be replicated during deserialization . This ensures to ensure that an attacker cannot glean extract sensitive information by deserializing the object.
Noncompliant Code Example
In this noncompliant code example, security manager checks are used within the constructor but are not replicated within omitted from the writeObject()
and readObject()
methods that are used in the serialization-deserialization process. This omission allows untrusted code to maliciously create instances of the class.
Code Block | ||
---|---|---|
| ||
public final class CreditCardHometown implements Serializable { // Private internal state private String credit_cardtown; private static final String DEFAULTUNKNOWN = "DEFAULT"; UNKNOWN"; void performSecurityManagerCheck() throws AccessDeniedException { // ... } void validateInput(String newCC) throws InvalidInputException { // ... } public CreditCardHometown() { performSecurityManagerCheck(); // Initialize credit_cardtown to default value credit_card = DEFAULTtown = UNKNOWN; } // Allows callers to retrieve internal state String getValue() { performSecurityManagerCheck(); return town; } // Allows callers to modify (private) internal state public void changeCCchangeTown(String newCCnewTown) { if (credit_cardtown.equals(newCCnewTown)) { // No change return; } else { performSecurityManagerCheck(); validateInput(newCCnewTown); credit_cardtown = newCCnewTown; } } private //void readObjectwriteObject(ObjectOutputStream out) correctly enforces checks during deserialization throws IOException { out.writeObject(town); } private void readObject(ObjectInputStream in) throws IOException { in.defaultReadObject(); // If the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!DEFAULTUNKNOWN.equals(credit_cardtown)) { validateInput(credit_cardtown); } } // Allows callers to retrieve internal state String getValue() { return credit_card; } // writeObject() correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) throws IOException { out.writeObject(credit_card); } } } |
(Although there are security manager checks, the data in this example is not sensitive. Serializing unencrypted sensitive data violates SER03-J. Do not serialize unencrypted sensitive data.)
AccessDeniedException
and InvalidInputException
are both security exceptions that can be thrown by any method without requiring a throws
declaration.
Compliant Solution
This compliant solution implements the required security manager checks in all constructors and methods that can either modify or retrieve internal state. As a resultConsequently, an attacker cannot create a modified instance of the object (using deserialization) or read the serialized byte stream to uncover sensitive reveal serialized data.
Code Block | ||
---|---|---|
| ||
public final class SecureCreditCardHometown implements Serializable { // Private... internalAll state methods the privatesame String credit_card; private static final String DEFAULT = "DEFAULT";except the following: public// SecureCreditCardwriteObject() { correctly enforces checks performSecurityManagerCheck(); // Initialize credit_card to default value credit_card = DEFAULT; } //allows callers to modify (private) internal state public void changeCC(String newCC) { if (credit_card.equals(newCC)) { // No change return; } else { // Check permissions to modify credit_card during serialization private void writeObject(ObjectOutputStream out) throws IOException { performSecurityManagerCheck(); validateInput(newCC); credit_card = newCC; }out.writeObject(town); } // readObject() correctly enforces checks during deserialization private void readObject(ObjectInputStream in) throws IOException { in.defaultReadObject(); // If the deserialized name does not match the default value normally // created at construction time, duplicate the checks if (!DEFAULTUNKNOWN.equals(credit_cardtown)) { performSecurityManagerCheck(); validateInput(credit_cardtown); } } // Allows callers to retrieve internal state public String getValue() { // Check permission to get value performSecurityManagerCheck(); return somePublicValue; } // writeObject() correctly enforces checks during serialization private void writeObject(ObjectOutputStream out) throws IOException { // Duplicate check from getValue() performSecurityManagerCheck(); out.writeObject(credit_card); } } |
Refer to the guideline SEC08SEC04-J. Enforce Protect sensitive operations with security checks in code that performs sensitive operations to learn manager checks for information about implementing the performSecurityManagerCheck()
method, which is important for protection against finalizer attacks.
The ObjectInputStream.defaultReadObject()
fills the object's fields with data from the input stream. Because each field is deserialized recursively, it is possible for the this
reference to escape from control of the deserialization routines. This can happen if a referenced object publishes the this
reference in its constructors or field initializers (see TSM01-J. Do not let the this reference escape during object construction for more information). To be compliant, recursively deserialized subobjects must not publish the this
object reference.
Risk Assessment
Allowing serialization or deserialization to bypass the Security Manager security manager may result in sensitive data being exposed or modifiedclasses being constructed without required security checks.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
SER04-J |
High |
Probable |
High | P6 | L2 |
Automated Detection
...
TODO
Related Vulnerabilities
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.SER04.SCSER | Enforce 'SecurityManager' checks in methods of 'Serializable' classes |
Related Guidelines
Guideline 8-4 / SERIAL-4: Duplicate the SecurityManager checks enforced in a class during serialization and deserialization |
Android Implementation Details
The java.security
package exists on Android for compatibility purposes only, and it should not be used.
Bibliography
Section 2.4, "Serialization" |
...
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[SCG 07|AA. Java References#SCG 07]\] Guideline 5-3 Duplicate the SecurityManager checks enforced in a class during serialization and deserialization
\[[Long 05|AA. Java References#Long 05]\] Section 2.4, Serialization |
SER04-J. Validate deserialized objects 14. Serialization (SER) SER06-J. Do not serialize instances of inner classes