Process Control

ID

java.process_control

Severity

critical

Resource

Injection

Language

Java

Tags

CWE:114, NIST.SP.800-53, OWASP:2021:A1, OWASP:2021:A8, PCI-DSS:6.5.8

Description

Improper neutralization of external input used in a process.

Rationale

Under Java, the load() and loadLibrary() methods, found in java.lang.System or java.lang.Runtime, facilitate loading native libraries. When using load(), a specific path to the library is specified.

Conversely, loadLibrary() only requires the library’s name, relying on a system-dependent search path, such as the java.library.path property or the LD_LIBRARY_PATH environment variable.

If these method arguments are influenced by untrusted input, including system environments or Java system properties, a security violation may be triggered.

For example, consider:

String libraryPath = System.getProperty("user.home") + "/lib/maliciousLibrary.so";
System.load(libraryPath);

Here, an attacker controlling the user.home property can redirect the library loading process, potentially substituting a malicious library.

Additionally, any invocation of loadLibrary() (if the configuration property alwaysReportLoadLibrary is true) will cause a code vulnerability to be reported due to documented insecurities:

Loads the dynamic library with the specified library name. A file containing native code is loaded from the local filesystem from locations where library files are conventionally found. This process is implementation-dependent, and library naming mappings are system-specific.

This behavior allows an attacker to insert a malicious library into the loading path, executing with elevated privileges if successful.

Remediation

To mitigate risks associated with loading native libraries, consider the following actions:

  • Prefer load() over loadLibrary(): Choose load() instead of loadLibrary() when feasible, to explicitly define the library’s path, minimizing the risk of unintentional library replacements by an attacker.

  • Sanitize Inputs: Never allow untrusted sources to dictate the name or path of the library being loaded. Ensure that all inputs are validated and sanitized before use.

  • Evaluate Environment Security: Although load() could be less portable due to explicit path definitions, understand your environment’s security configuration thoroughly. If factors allow, you might disable the alwaysReportLoadLibrary configuration property, but only if your environment guarantees the integrity of system library paths.

Through these practices, applications can better safeguard against library loading attacks and maintain control over which code executes within their environment.

Configuration

The detector has the following configurable parameters:

  • alwaysReportLoadLibrary, that indicates if using loadLibrary() should be considered always insecure.

  • sources, that indicates the source kinds to check.

  • neutralizations, that indicates the neutralization kinds to check.

References