SEC33-J. Define wrappers around native methods

Native methods are defined in Java and written in traditional languages such as C and C++ [[JNI 06]]). The added extensibility comes at the cost of flexibility and portability as the code no longer conforms to the policies enforced by Java. In the past, native method were used for performing platform specific operations, interfacing with legacy library code and improving program performance [[Bloch 08]]. Although this is not completely true in present times (due to poor portability, safety and quite ironically, performance issues), they are still used to interface with legacy code.

Defining a wrapper method facilitates carrying out security manager checks, perform input validation before passing the arguments to the native code, defensively copy mutable inputs and sanitize user supplied input.

Noncompliant Code Example

Security manager checks are not conducted in case of native method invocations. Additionally, as demonstrated in the noncompliant code example, it is easy to overlook proper input validation before the call. The doOperation method invokes the nativeOperation native method but fails. Also, the access specifier of the native method is public which raises risks associated with untrusted callers to provide adequate validation. (Note that native methods may even increase susceptibility to non-Java specific vulnerabilities, such as buffer overflows.)

public final class NativeMethod {

  // private native method
  private native void nativeOperation(byte[] data, int offset, int len);

  // wrapper method that does not perform any security checks or input validation
  public void doOperation(byte[] data, int offset, int len) {
    nativeOperation(data, offset, len);
  }
  
  static {
    System.loadLibrary("NativeMethodLib"); //load native library in static initializer of class
  }
}

Compliant Solution

This compliant solution makes the actual native method private and defines a public wrapper that calls securityManagerCheck() which in turn performs routine permission checks to determine if the succeeding operations can continue. This is followed by input range checking and creation of a copy of the mutable input array, data. Finally the nativeOperation method is called with sanitized inputs. Ensure that the validation checks produce outputs that are coherent with the input requirements of the native implementations/libraries.

public final class NativeMethodWrapper {

  // private native method
  private native void nativeOperation(byte[] data, int offset, int len);

  // wrapper method performs SecurityManager and input validation checks
  public void doOperation(byte[] data, int offset, int len) {
    // permission needed to invoke native method
    securityManagerCheck();

    if (data == null) {
      throw new NullPointerException();
    }

    // copy mutable input
    data = data.clone();

    // validate input
    if ((offset < 0) || (len < 0) || (offset > (data.length - len))) {
      throw new IllegalArgumentException();
    }

    nativeOperation(data, offset, len);
  }

  static {
    System.loadLibrary("NativeMethodLib"); //load native library in static initializer of class
  }
}

Risk Assessment

Allowing native methods to be called directly by untrusted code may seriously compromise the security of a Java application.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[JNI 06]]
[[SCG 07]] Guideline 3-3 Define wrappers around native methods
[[Liang 97]]
[[Macgregor 98]] Section 2.2.3, Interfaces and Architectures
[[MITRE 09]] CWE ID 111 "Direct Use of Unsafe JNI"

SEC32-J. Do not grant ReflectPermission with action suppressAccessChecks      00. Security (SEC)      SEC10-J. Do not allow the unauthorized construction of sensitive classes