You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 52 Next »

Security checks based on untrusted sources can be bypassed. The untrusted object or parameter should be defensively copied before the security check is performed. The copy operation must be a deep copy; the implementation of the clone() method may produce a shallow copy, which can still be compromised. In addition, the implementation of the clone() method can be provided by the attacker. See rule OBJ06-J. Defensively copy mutable inputs and mutable internal components for more information.

Noncompliant Code Example

This noncompliant code example describes a security vulnerability from the Java 1.5 java.io package. In this release, java.io.File was nonfinal, allowing an attacker to supply an untrusted argument constructed by extending the legitimate File class. In this manner, the getPath() method can be overridden so that the security check passes the first time it is called but the value changes the second time to refer to a sensitive file such as /etc/passwd. This is a form of 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 could 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 (Final)

This vulnerability can be mitigated by declaring java.io.File final.

Compliant Solution (Copy)

This compliant solution ensures that the java.io.File object can be trusted despite not being final. The solution creates a new File object using the standard constructor. This ensures that any methods invoked on the File object are the standard library methods rather than overriding methods that may be provided by the attacker.

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());
    }
  }
}

Note that using the clone() method instead of the openFile() method would copy the attacker's class, which is not desirable. (Refer to rule OBJ06-J. Defensively copy mutable inputs and mutable internal components.)

Risk Assessment

Basing security checks on untrusted sources can result in the check being bypassed.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC02-J

high

probable

medium

P12

L1

Related Guidelines

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="71bbb0e8-b2a1-40d2-a471-8ec9368488a7"><ac:plain-text-body><![CDATA[

[ISO/IEC TR 24772:2010

http://www.aitcnet.org/isai/]

Authentication Logic Error [XZO]

]]></ac:plain-text-body></ac:structured-macro>

MITRE CWE

CWE-302. Authentication bypass by assumed-immutable data

 

CWE-470. Use of externally-controlled input to select classes or code ("unsafe reflection")

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="64148d49-e848-4221-ae48-0e4a62d89ee6"><ac:plain-text-body><![CDATA[

[[Sterbenz 2006

AA. Bibliography#Sterbenz 06]]

]]></ac:plain-text-body></ac:structured-macro>


      14. Platform Security (SEC)      

  • No labels