Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%
Buy Us a Coffee

CWE-111 (对不安全JNI的直接使用) — Vulnerability Class 2

2 vulnerabilities classified as CWE-111 (对不安全JNI的直接使用). AI Chinese analysis included.

CWE-111, Direct Use of Unsafe JNI, is a critical weakness occurring when Java applications invoke native code via the Java Native Interface, thereby bypassing Java’s inherent safety mechanisms. This vulnerability typically arises because native languages like C or C++ lack memory safety guarantees, allowing attackers to exploit buffer overflows or memory corruption within the native layer to execute arbitrary code or crash the application. Since these flaws exist outside Java’s controlled environment, standard runtime protections often fail to detect them. Developers can mitigate this risk by rigorously validating all inputs passed to native functions, ensuring strict bounds checking, and minimizing the surface area of native code. Additionally, employing static analysis tools to scan native libraries and adhering to secure coding standards for C/C++ are essential practices to prevent unsafe interactions between Java and native environments.

MITRE CWE Description
When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java. Many safety features that programmers may take for granted do not apply for native code, so you must carefully review all such code for potential problems. The languages used to implement native code may be more susceptible to buffer overflows and other attacks. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking.
Common Consequences (1)
Access ControlBypass Protection Mechanism
Mitigations (3)
ImplementationImplement error handling around the JNI call.
ImplementationDo not use JNI calls if you don't trust the native library.
ImplementationBe reluctant to use JNI calls. A Java API equivalent may exist.
Examples (1)
The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. The following C code defines the native method implemented in the Echo class:
class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } }
Bad · Java
#include <jni.h> #include "Echo.h"//the java class above compiled with javah #include <stdio.h> JNIEXPORT void JNICALL Java_Echo_runEcho(JNIEnv *env, jobject obj) { char buf[64]; gets(buf); printf(buf); }
Bad · C
CVE IDTitleCVSSSeverityPublished
CVE-2018-12549 Eclipse OpenJ9 输入验证错误漏洞 — Eclipse OpenJ9 9.8 -2019-02-11
CVE-2016-9160 SIMATIC WinCC和SIMATIC PCS 7 安全漏洞 — SIEMENS SIMATIC WinCC (All versions < SIMATIC WinCC V7.2) and SIEMENS SIMATIC PCS 7 (All versions < SIMATIC PCS 7 V8.0 SP1) 8.1 -2016-12-17

Vulnerabilities classified as CWE-111 (对不安全JNI的直接使用) represent 2 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.