Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

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 because the code no longer conforms to the policies enforced by Java.

Noncompliant Code Example

. 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.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 on multiple validation angles. Also, the access specifier of the native method is public which raises risks associated with untrusted callers. (Note that native methods may even increase susceptibility to non-Java specific vulnerabilities, such as buffer overflows.)

Code Block
bgColor#FFcccc

public final class NativeMethod {

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

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

Compliant Solution

This compliant solution makes declares 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 . The doOperation() wrapper method checks permissions, creates a defensive copy of the mutable input array , data. Finally the nativeOperation method is called with sanitized inputs. Ensure 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 are coherent with conform to the input requirements of the native implementations/librariesmethods.

Code Block
bgColor#ccccff

public final class NativeMethodWrapper {

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

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

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

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

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

        nativeOperation(data, offset, len);
    }

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

Exceptions

JN100-J-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

Allowing Failure to define wrappers around native methods to be called directly by untrusted code may seriously compromise the security of a Java applicationcan allow unprivileged callers to invoke them and exploit inherent vulnerabilities such as buffer overflows in native libraries.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC33

JNI00-J

medium

Medium

probable

Probable

high

High

P??

L??

Automated Detection

TODO

Related Vulnerabilities

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

References

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.

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.JNI00.NATIWUse wrapper methods to secure native methods

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"


...

Image Added Image Added Image Added Wiki Markup\[[SCG 07|AA. Java References#SCG 07]\] \[[Liang 97|AA. Java References#Liang 97]\] \[[Macgregor 98|AA. Java References#Macgregor 98]\] 2.2.3 Interfaces and Architectures