You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 99 Next »

Native methods are defined in Java and written in languages such as C and C++ [JNI 2006]. The added extensibility comes at the cost of flexibility and portability because the code no longer conforms to the policies enforced by Java. Native methods have been used for performing platform-specific operations, interfacing with legacy library code, and improving program performance [Bloch 2008].

Defining a wrapper method facilitates installing appropriate security manager checks, validating arguments passed to native code, validating return values, defensively copying mutable inputs, and sanitizing untrusted data. Consequently, every native method must be private and must be invoked only by a wrapper method.

Noncompliant Code Example

In this noncompliant code example, the nativeOperation() method is both native and public; consequently, untrusted callers may invoke it. Native method invocations bypass security manager checks.

This example includes the doOperation() wrapper method, which invokes the nativeOperation() native method but fails to provide input validation or security checks.

public final class NativeMethod {

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

  // Wrapper method that lacks security checks and 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. The doOperation() wrapper method checks permissions, creates a defensive copy of the mutable input array data, and checks the ranges of the arguments. The nativeOperation() method is consequently called with secure inputs. Note that the validation checks must produce outputs that conform to the input requirements of the native methods.

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"); 
  }
}

Exceptions

JN100-EX0: Native methods that do not require security manager checks, validation of arguments or return values, or defensive copying of mutable inputs (for example, the standard C function int rand(void)) do not need to be wrapped.

Risk Assessment

Failure to define wrappers around native methods can allow unprivileged callers to invoke them and exploit inherent vulnerabilities such as buffer overflows in native libraries.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

JNI00-J

Medium

Probable

High

P4

L3

Automated Detection

Automated detection is not feasible in the fully general case. However, an approach similar to Design Fragments [Fairbanks 2007] could assist both programmers and static analysis tools.

Related Guidelines

MITRE CWE

CWE-111, Direct Use of Unsafe JNI

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 5-3 / INPUT-3: Define wrappers around native methods

Bibliography

[Fairbanks 2007]

 

[JNI 2006]

 

[Liang 1997]

 

[Macgregor 1998]

Section 2.2.3, "Interfaces and Architectures"

 


  • No labels