Versions Compared

Key

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

Wiki Markup Native methods are defined in Java and written in traditional languages such as C and C++ \ [[JNI 2006|AA. Bibliography#JNI 06]\]. The added extensibility comes at the cost of flexibility and portability as because 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|AA. Bibliography#Bloch 08]\]. Although this is no longer completely true --- because of poor portability, safety and (quite ironically) performance issues --- native code is still used to interface with legacy codeNative 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, performing input validation before passing the arguments to the native code or when obtaining validating arguments passed to native code, validating return values, defensively copying mutable inputs, and sanitizing user input. As a result 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; for that reasonconsequently, untrusted callers may invoke it. Native method invocations bypass security manager checks.

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

Code Block
bgColor#FFcccc

public final class NativeMethod {

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

  // wrapperWrapper method that lacks security checks and input validation
  public void doOperation(byte[] data, int offset, int len) {
    nativeOperation(data, offset, len);
  }
  
  static {
    // loadLoad native library in static initializer of class
    System.loadLibrary("NativeMethodLib"); 
  }
}

Compliant Solution

This compliant solution declares the native method private. Furthermore, the The doOperation() wrapper method performs routine permission checking to determine whether the succeeding operations are permitted to continue. This is followed by the creation of checks permissions, creates a defensive copy of the mutable input array data as well as by range checking , and checks the ranges of the parametersarguments. The nativeOperation() method is consequently called with safe secure inputs. Note that the validation checks must produce outputs that 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 {
    // loadLoad 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

Failure to define wrappers around native methods can allow unprivileged callers to invoke them and consequently exploit inherent vulnerabilities such as those resulting from invalid inputsbuffer overflows in native libraries.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC08

JNI00-J

medium

Medium

probable

Probable

high

High

P4

L3

Automated Detection

Wiki MarkupAutomated detection is not feasible in the fully general case. However, an approach similar to Design Fragments \[ [Fairbanks 07|AA. Bibliography#Fairbanks 07]\] could assist both programmers and static analysis tools.

Related Vulnerabilities

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

Related Guidelines

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3db87b43-56f5-41f1-8048-9ba3e0fb03c9"><ac:plain-text-body><![CDATA[

[[MITRE 2009

AA. Bibliography#MITRE 09]]

[CWE ID 111

http://cwe.mitre.org/data/definitions/111.html] "Direct Use of Unsafe JNI"

]]></ac:plain-text-body></ac:structured-macro>

Bibliography

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

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2bcbdd59-7e37-4398-a69b-373097a6855b"><ac:plain-text-body><![CDATA[

[[Fairbanks 2007

AA. Bibliography#Fairbanks 07]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7c1e85b1-d9a1-434b-b2d5-b906ec2e118a"><ac:plain-text-body><![CDATA[

[[JNI 2006

AA. Bibliography#JNI 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7045c3a1-2ebb-4f53-82f3-d94a4b28943c"><ac:plain-text-body><![CDATA[

[[Liang 1997

AA. Bibliography#Liang 97]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="888647e4-9489-49f1-bbb8-9dc46d078730"><ac:plain-text-body><![CDATA[

[[Macgregor 1998

AA. Bibliography#Macgregor 98]

]

Section 2.2.3, "Interfaces and Architectures

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name=

"

unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d3a84dbd-0adf-4627-9edf-58b57c7e9a88"><ac:plain-text-body><![CDATA[

[[SCG 2009

AA. Bibliography#SCG 09]]

Guideline 3-3 Define wrappers around native methods

]]></ac:plain-text-body></ac:structured-macro>


...

Image Added Image Added Image AddedSEC07-J. Call the superclass's getPermissions method when writing a custom class loader      14. Platform Security (SEC)      SEC09-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar