J2EE Bad Practices: Use of System.exit()

Draft Variant
Structure: Simple
Description

This vulnerability occurs when a J2EE application directly calls System.exit(), which forcibly terminates the entire application server process, not just the application itself.

Extended Description

Calling System.exit() from within a deployed J2EE application is a dangerous anti-pattern. It grants a single application the power to shut down the shared container, crashing every other application and service running on the same server. This creates a severe reliability issue and an immediate vector for Denial-of-Service (DoS) attacks, as even an unprivileged user might trigger a code path that calls this method. Instead of using System.exit(), applications should manage their lifecycle gracefully through the container's administrative interfaces. Error conditions should be handled using exception mechanisms that log the issue and return an appropriate error response to the user, allowing the container and other co-hosted applications to continue running normally. This approach maintains system stability and aligns with the managed, multi-application environment that J2EE containers are designed to provide.

Common Consequences 1
Scope: Availability

Impact: DoS: Crash, Exit, or Restart

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 4
Phase: Architecture and Design

Strategy: Separation of Privilege

The shutdown function should be a privileged function available only to a properly authorized administrative user
Phase: Implementation
Web applications should not call methods that cause the virtual machine to exit, such as System.exit()
Phase: Implementation
Web applications should also not throw any Throwables to the application server as this may adversely affect the container.
Phase: Implementation
Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code
Demonstrative Examples 1

ID : DX-199

Included in the doPost() method defined below is a call to System.exit() in the event of a specific exception.

Code Example:

Bad
Java
java
References 1
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and MetricsNIST
07-11-2005
ID: REF-6
Applicable Platforms
Languages:
Java : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
  • 7 Pernicious Kingdoms
  • OWASP Top Ten 2004
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • Software Fault Patterns