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 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 codeNative methods have been used for performing platform-specific operations, interfacing with legacy library code, and improving program performance [Bloch 2008]. Wiki Markup
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 untrusted data. Consequently, every native method must be private and must be invoked only by a wrapper method.
Noncompliant Code Example
Security manager checks are not automatically enforced in case of native method invocations. Additionally, as demonstrated in In this noncompliant code example, the nativeOperation()
method is both native and public; consequently, it is easy to overlook proper input validation before the call. The 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 adequate input validation . Also, the access specifier of the native method is public
which allows untrusted callers to invoke the method. or security checks.
Code Block | ||
---|---|---|
| ||
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 { // loadLoad 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. The doOperation()
method. This method performs routine permission checking to determine if the succeeding operations can continue. This is followed by the creation of a wrapper method checks permissions, creates a defensive copy of the mutable input array data
, data
and input range checking and checks the ranges of the parametersarguments. Finally the The nativeOperation()
method is consequently called with safe secure inputs. Ensure Note that the validation checks must produce outputs that are coherent with conform to the input requirements of the native implementations/librariesmethods.
Code Block | ||
---|---|---|
| ||
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 exploit inherent vulnerabilities such as the ones resulting from invalid input validationbuffer overflows in native libraries.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
JNI00-J |
Medium |
Probable |
High | P4 | L3 |
Automated Detection
...
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
...
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.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.JNI00.NATIW | Use wrapper methods to secure native methods |
Related Guidelines
CWE-111, Direct Use of Unsafe JNI | |
Guideline 5-3 / INPUT-3: Define wrappers around native methods |
Bibliography
[JNI 2006] | |
Section 2.2.3, |
...
"Interfaces |
...
and |
...
Architectures" |
...
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 111|http://cwe.mitre.org/data/definitions/111.html] "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