When security checks are based on untrusted sources, those sources could be compromised in such a way that the security check could be bypassed. The untrusted object or parameter should be defensively copied before the security check is carried out. The copy operation must be a deep copy; the implementation of the clone()
method may produce a shallow copy, which could still be compromised. Further, the implementation of the clone()
method can be provided by the attacker. See guidelines MET08-J. Do not use the clone method to copy untrusted method parameters and FIO00-J. Defensively copy mutable inputs and mutable internal components for more information.
Noncompliant Code Example
This noncompliant code example describes a security vulnerability from JDK 5.0 software. At the time, java.io.File
was non-final, allowing an attacker to supply an untrusted value as a parameter which was constructed by extending the legitimate java.io.File
class. In this way, the getPath()
method could be overridden so that the security check passes the first time it is called but the value mutates the second time to refer to a sensitive file such as /etc/passwd
. This is a time-of-check-time-of-use (TOCTOU) vulnerability.
public RandomAccessFile openFile(final java.io.File f) { askUserPermission(f.getPath()); // ... return (RandomAccessFile)AccessController.doPrivileged() { public Object run() { return new RandomAccessFile(f.getPath()); } } }
The attacker can extend java.io.File
as follows:
public class BadFile extends java.io.File { private int count; public String getPath() { return (++count == 1) ? "/tmp/foo" : "/etc/passwd"; } }
Compliant Solution
Security checks should not be based on untrusted sources. This compliant solution ensures that the java.io.File
object can be trusted because
- our reference to it is declared to be
final
. Thus, we know that the attacker cannot modify the reference and substitute a different object. - we create our own new
java.io.File
object using the standardjava.io.File
constructor. This ensures that any methods we invoke on theFile
object are the standard library methods rather than overriding methods potentially provided by the attacker.
Note that using the clone()
method instead of the openFile()
method would copy the attacker's class, which is not desirable. (Refer to guideline MET08-J. Do not use the clone method to copy untrusted method parameters.)
public RandomAccessFile openFile(java.io.File f) { final java.io.File copy = new java.io.File(f.getPath()); askUserPermission(copy.getPath()); // ... return (RandomAccessFile)AccessController.doPrivileged() { public Object run() { return new RandomAccessFile(copy.getPath()); } } }
Risk Assessment
Basing security checks on untrusted sources can result in the check being bypassed.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SEC09-J |
high |
probable |
medium |
P12 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Related Guidelines
MITRE CWE: CWE-302 "Authentication Bypass by Assumed-Immutable Data"
Bibliography
[[Sterbenz 2006]]
SEC08-J. Protect sensitive operations with security manager checks 02. Platform Security (SEC) SEC10-J. Define custom security permissions for fine grained security