SEC18-J. Define wrappers around native methods

Native methods are defined in Java and written in traditional languages such as C and C++ [[JNI 2006]]. 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 methods were used for performing platform specific operations, interfacing with legacy library code and improving program performance [[Bloch 2008]]. Although this is not completely true in present times (because of poor portability, safety and quite ironically, performance issues), native code is still used to interface with legacy code.

Defining a wrapper method facilitates installing appropriate security manager checks, performing input validation before passing the arguments to the native code or when obtaining return values, defensively copying mutable inputs and sanitizing user input.

Noncompliant Code Example

Security manager checks are not automatically enforced in case of native method invocations. Additionally, as demonstrated in this noncompliant code example, it is easy to overlook proper input validation before the call. The doOperation() method invokes the nativeOperation() native method but fails to provide adequate input validation. Also, the access specifier of the native method is public which allows untrusted callers to invoke the method.

public final class NativeMethod {

  // public native method
  public 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 {
    // load native library in static initializer of class
    System.loadLibrary("NativeMethodLib"); 
  }
}

Compliant Solution

This compliant solution declares the native method private and defines a public wrapper that calls the securityManagerCheck() method. This method performs routine permission checking to determine if the succeeding operations can continue. This is followed by the creation of a copy of the mutable input array, data and input range checking of the parameters. Finally the nativeOperation() method is called with safe 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 {
    // load native library in static initializer of class
    System.loadLibrary("NativeMethodLib"); 
  }
}

Risk Assessment

Failure to define wrappers around native methods can allow unprivileged callers to invoke them and exploit inherent vulnerabilities such as the ones resulting from invalid input validation.

Automated Detection

TODO

Related Vulnerabilities

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

Bibliography

[[JNI 2006]]
[[SCG 2007]] Guideline 3-3 Define wrappers around native methods
[[Liang 1997]]
[[Macgregor 1998]] Section 2.2.3, Interfaces and Architectures
[[MITRE 2009]] CWE ID 111 "Direct Use of Unsafe JNI"

SEC17-J. Create and sign a SignedObject before creating a SealedObject      02. Platform Security (SEC)      SEC19-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar