...
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
Native method invocations bypass security manager checks. Additionally, as demonstrated in this noncompliant code example, it is easy to overlook proper input validation before the native method invocation. The doOperation()
method invokes the nativeOperation()
native method but fails to provide adequate input validation. Further, untrusted callers can invoke the native method because its access specifier is public
.
Code Block | ||
---|---|---|
| ||
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
and defines a public
wrapper that calls the securityManagerCheck()
method. The wrapper method performs routine permission checking to determine whether the succeeding operations are permitted to continue. This is followed by the creation of a defensive copy of the mutable input array data
as well as by range checking of the parameters. The nativeOperation()
method is thus called with safe inputs. Note that the validation checks must produce outputs that conform to the input requirements of the native implementations/libraries.
Code Block | ||
---|---|---|
| ||
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 thus exploit inherent vulnerabilities such as those resulting from invalid inputs.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
SEC18-J | medium | probable | high | P4 | L3 |
Automated Detection
Wiki Markup |
---|
Automated 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 guideline on the CERT website.
Bibliography
Wiki Markup |
---|
\[[Fairbanks 2007|AA. Bibliography#Fairbanks 07]\] \[[JNI 2006|AA. Bibliography#JNI 06]\] \[[Liang 1997|AA. Bibliography#Liang 97]\] \[[Macgregor 1998|AA. Bibliography#Macgregor 98]\] 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" \[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 3-3 Define wrappers around native methods |
...