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]