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

Compare with Current View Page History

Version 1 Next »

If the program relies on finalize() to release system resources, or there is confusion over which part of the program is responsible for releasing system resources, then there exists a possibility for a potential resource leak. In a busy system, there might be a time gap before the finalize() method is called for an object. An attacker might exploit this vulnerability to induce a Denial of Service attack.

If there is unreleased memory, eventually the Java garbage collector will be called to free memory; however, if the program relies on non-memory resources like file descriptors  and database connections, unreleased resources might lead the program to prematurely exhaust it's pool of resources. In addition, if the program uses resources like Lock or Semaphore, waiting for finalize() to release the resources may lead to resource starvation.

Noncompliant Code Example

The worst form of non-compliance is not calling methods to release the resource at all. If files are opened, they must be explicitly closed when their work is done.

public String processFile(String fileName) throws IOException, FileNotFoundException {
     FileInputStream stream = new FileInputStream(fileName);
     props.load(stream);
     stream.close();
     return props;
}


try {
      System.setSecurityManager(null);
} catch (SecurityException se) { System.out.println("SecurityManager is already set\!"); }

Any Java program (bean, servlet or application) can instantiate a SecurityManager. However, for applications designed to run locally, an explicit flag must be set to enforce the SecurityManager policy. In the noncompliant example highlighted next, this flag has not been used which circumvents all SecurityManager checks.

java application

Compliant Solution

This compliant solution demonstrates how a custom SecurityManager class called CustomSecurityManager can be activated by invoking its constructor with a password. Various check methods defined within the class can then be invoked to perform access checks. Alternatively, to use the default security manager change the active instance to java.lang.SecurityManager.

try {
      System.setSecurityManager(new CustomSecurityManager("password here"));
      SecurityManager sm = System.getSecurityManager();
      if(sm \!= null) {  //check if file can be read
        FilePermission perm = new FilePermission("/temp/tempFile", "read");
        sm.checkPermission(perm);
      }
} catch (SecurityException se) { System.out.println("SecurityManager is already set\!"); }

For local applications, the security manager can be installed using the flags as shown next. Note that the setSecurityManager method must be replaced by getSecurityManager in this case since the manager has already been installed using the command line flag.

java \-Djava.security.manager \-Djava.security.policy=policyURL LocalJavaApp

By default, the SecurityManager checkPermission method(s) forward all calls to the java.security.Accesscontroller.checkPermission. Sometimes it is required to perform checks against a different context than the currently executing threads' context. This can be done using the checkPermission(Permission perm, Object context) method which takes an extra argument (like AccessControlContext) as the context of the desired thread.

The document [[Policy 02|AA. Java References#Policy 02]] discusses writing policy files in depth.

Risk Assessment

Running Java code without a Security Manager being set means that there is no security at all.
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| SEC30-J | high | probable | low | P18 | L1 |

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+SEC30-J].

References

[[API 06|AA. Java References#API 06]] [Class SecurityManager|http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html]
[[Policy 02|AA. Java References#Policy 02]]
[[Pistoia 04|AA. Java References#Pistoia 04]] Section 7.4, The Security Manager
[[Gong 03|AA. Java References#Gong 03]] Section 6.1, Security Manager

----
[!CERT Java Secure Coding Standard^button_arrow_left.png|width=32,height=32!|SEC07-J. Minimize accessibility]      [!CERT Java Secure Coding Standard^button_arrow_up.png|width=32,height=32!|00. Security (SEC)]      [!CERT Java Secure Coding Standard^button_arrow_right.png|width=32,height=32!|SEC31-J. Never grant AllPermission to untrusted code]

  • No labels