Page History

When Invocation of System.exit() terminates the Java Virtual Machine (JVM) is invoked, consequently terminating all running programs and threads running on the JVM terminate. This can result in denial-of-service attacks, for (DoS) attacks. For example, a web server can stop servicing users upon encountering an untimely call to System.exit(call to System.exit() that is embedded in Java Server Pages (JSP) code can cause a web server to terminate, preventing further service for users. Programs must prevent both inadvertent and malicious calls to System.exit(). Additionally, programs should perform necessary cleanup actions when forcibly terminated (for example, by using the Windows Task Manager, POSIX kill command, or other mechanisms).

Noncompliant Code Example

This noncompliant code example calls uses System.exit() to forcefully shutdown shut down the JVM and terminate the running process. No security manager checks have been installed The program lacks a security manager; consequently, it lacks the capability to check whether the program has sufficient permissions to exitcaller is permitted to invoke System.exit().

public class InterceptExit {
  public static void main(String[] args) {
    // ...
    System.exit(1);  // Abrupt exit 
    System.out.println("This is never executedexecutes");
  }
}	

Compliant Solution

This compliant solution installs a custom security manager PasswordSecurityManager that overrides the checkExit() method defined in the SecurityManager class. An internal flag is used to keep track of whether the exit is permitted or not. The method setExitAllowed() is used to set this flag. If the flag is not set (false), a SecurityException is thrown. The System.exit() call is not allowed to execute by catching the SecurityException in a try-catch block. After intercepting and performing mandatory clean-up operations, the setExitAllowed() method is invoked. As a result, the program exits gracefullyThis override is required to enable invocation of cleanup code before allowing the exit. The default checkExit() method in the SecurityManager class lacks this facility.

class PasswordSecurityManager extends SecurityManager {
  private boolean isExitAllowedFlag; 
  
  public PasswordSecurityManager(){
    super();
    isExitAllowedFlag = false;  
  }
 
  public boolean isExitAllowed(){
    return isExitAllowedFlag;	 
  }
 
  @Override 
  public void checkExit(int status) {
    if (!isExitAllowed()) {
      throw new SecurityException();
    }
    super.checkExit(status);
  }
 
  public void setExitAllowed(boolean f) {
    isExitAllowedFlag = f; 	 
  }
}

public class InterceptExit {
  public static void main(String[] args) {
    PasswordSecurityManager secManager =
        new PasswordSecurityManager();
    System.setSecurityManager(secManager);
    try {
      // ...
      System.exit(1);  // Abrupt exit call
    }
    catch (Throwable x) {
      if (x instanceof SecurityException) {
        System.out.println("Intercepted System.exit()");
        // Log exception
      } else {
        // Forward to exception handler
      }
    }

    // ...
    secManager.setExitAllowed(true);  // Permit exit
    // System.exit() will work subsequently
    // ...
  }
}

Noncompliant Code Example

If a user forcefully exits a program by pressing the ctrl + c key or uses the kill command, the JVM terminates abruptly. Although this event cannot be captured, the code should be able to react to it. This noncompliant code example misses this step.

public class InterceptExit {
  public static void main(String[] args) {
    System.out.println("Regular code block");
    // Abrupt exit such as ctrl + c key pressed
    System.out.println("This never executes");
  }
}

Compliant Solution

The addShutdownHook() method of java.lang.Runtime helps to perform clean-up operations in the abrupt termination scenario. When the shutdown is initiated, the hook thread starts to run concurrently with other JVM threads.

According to the Java API \[[API 06|AA. Java References#API 06]\] Class {{Runtime}}, method {{addShutdownHook}}:

A shutdown hook is simply an initialized but unstarted thread. When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently. When all the hooks have finished it will then run all uninvoked finalizers if finalization-on-exit has been enabled. Finally, the virtual machine will halt. Once the shutdown sequence has begun it can be stopped only by invoking the halt method, which forcibly terminates the virtual machine. Once the shutdown sequence has begun it is impossible to register a new shutdown hook or de-register a previously-registered hook.

As the JVM is in a sensitive state during this stage, some precautions must be taken:

• Hook threads should be light-weight and simple
• They should be thread safe
• They should hold locks when accessing data

• Wiki Markup
  They should not rely on system services as the services themselves may be shutting down (for example, the logger may shutdown from another hook). Instead of one service it may be better to run a series of shutdown tasks from one thread by using a single shutdown hook. \[[Goetz 06|AA. Java References#Goetz 06]\]

This compliant solution shows the method to install a hook.

public class Hook {
  public static void main(String[] args) {
    Runtime.getRuntime().addShutdownHook(new Thread() {
      public void run() {
        hookShutdown();
      }
    });
		
   // ...
  }

  public static void hookShutdown() {
    // Log shutdown and close all resources
  }
}

It is still possible for the JVM to abort because of external issues, such as an external SIGKILL signal (UNIX) or the TerminateProcess call (Microsoft Windows), or memory corruption caused by native methods. In such cases, it is not guaranteed that the hooks will execute as expected.

Exceptions

*EX1:* It is permissible for a command line utility to call {{System.exit()}} or terminate prematurely, for example, when the required number of arguments are not input. \[[Bloch 08|AA. Java References#Bloch 08]\] and \[[ESA 05|AA. Java References#ESA 05]\]

Risk Assessment

This implementation uses an internal flag to track whether the exit is permitted. The method setExitAllowed() sets this flag. The checkExit() method throws a SecurityException when the flag is unset (that is, false). Because this flag is not initially set, normal exception processing bypasses the initial call to System.exit(). The program catches the SecurityException and performs mandatory cleanup operations, including logging the exception. The System.exit() method is enabled only after cleanup is complete.

Exceptions

ERR09-J-EX0: It is permissible for a command-line utility to call System.exit(), for example, when the required number of arguments are not input [Bloch 2008], [ESA 2005].

Risk Assessment

Allowing unauthorized Allowing inadvertent calls to System.exit() may lead to denial of service.

Automated Detection

...

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[API 06|AA. Java References#API 06]\] [method checkExit()|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/SecurityManager.html#checkExit(int)], Class Runtime, method addShutdownHook
\[[Kalinovsky 04|AA. Java References#Kalinovsky 04]\] Chapter 16 Intercepting a Call to System.exit
\[[Austin 00|AA. Java References#Austin 00]\] [Writing a Security Manager|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed2.html]
\[[Darwin 04|AA. Java References#Darwin 04]\] 9.5 The Finalize Method
\[[Goetz 06|AA. Java References#Goetz 06]\] 7.4. JVM Shutdown 
\[[ESA 05|AA. Java References#ESA 05]\] Rule 78: Restrict the use of the System.exit method 
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 382|http://cwe.mitre.org/data/definitions/382.html] "J2EE Bad Practices: Use of System.exit()"

Tool	Version	Checker	Description
CodeSonar	Include Page CodeSonar_V CodeSonar_V	JAVA.DEBUG.CALL	Debug Call (Java)
Coverity	7.5	DC.CODING_STYLE FB.DM_EXIT	Implemented
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.ERR09.JVM CERT.ERR09.EXIT	Do not stop the JVM in a web component Do not call methods which terminates Java Virtual Machine
SonarQube	Include Page SonarQube_V SonarQube_V	S1147	Exit methods should not be called

Related Guidelines

Android Implementation Details

On Android, System.exit() should not be used because it will terminate the virtual machine abruptly, ignoring the activity life cycle, which may prevent proper garbage collection.

Bibliography

...

Image Added Image Added Image AddedEXC08-J. Try to gracefully recover from system errors      13. Exceptional Behavior (EXC)      EXC01-J. Use a class dedicated to reporting exceptions