Unsafe JNI

JNI(Java Native Interface)의 잘못된 사용으로 Java 응용 프로그램이 다른 언어의 보안 결함에 취약해질 수 있습니다.

Unsafe JNI 오류는 Java 응용 프로그램이 JNI를 사용하여 다른 프로그래밍 언어로 작성된 코드를 호출할 때 발생합니다.
예제 1: 다음 Java 코드는 Echo라는 클래스를 정의합니다. 클래스는 C를 사용하여 콘솔에 입력된 명령을 사용자에게 돌려보내는 하나의 네이티브 메서드를 선언합니다.

    class Echo {
	public native void runEcho();

	static {
		System.loadLibrary("echo");
		}

	public static void main(String[] args) {
		new Echo().runEcho();
		}
}

다음 C 코드는 Echo 클래스에서 구현된 네이티브 메서드를 정의합니다.

#include <jni.h>
#include "Echo.h" //javah로 컴파일된 Example 1의 Java 클래스
#include <stdio.h>

JNIEXPORT void JNICALL
Java_Echo_runEcho(JNIEnv *env, jobject obj)
{
	char buf[64];
	gets(buf);
	printf(buf);
}

이 예제는 Java로 구현되었기 때문에 buffer overflow 취약점과 같은 메모리 문제가 없는 것처럼 보입니다. Java가 메모리 연산을 안전하게 수행하는 뛰어난 기능이 있지만 이 보호 기능이 JNI(Java Native Interface)를 통해 접근하는 다른 언어로 작성된 소스 코드에서 발생하는 취약점에까지 적용되지는 않습니다. Java의 메모리 보호 기능에도 불구하고, 이 예제의 C 코드는 입력에 대해 범위 검사를 수행하지 않는 gets()를 사용하기 때문에 buffer overflow에 취약합니다.

Sun Java(TM) Tutorial에 JNI에 대한 다음과 같은 설명이 나와 있습니다[1]:

JNI 프레임워크에서는 Java 코드가 Java 개체를 사용하는 것과 같은 방식으로 네이티브 메서드가 Java 개체를 사용할 수 있습니다. 네이티브 메서드는 배열과 문자열을 포함한 Java 개체를 만들고 검사하고 작업을 수행하는 데 사용할 수 있습니다. 네이티브 메서드는 Java 응용 프로그램 코드에서 만든 개체를 검사하고 사용할 수도 있습니다. 또한 네이티브 메서드는 Java가 만들었거나 Java에 전달된 Java 개체를 업데이트할 수도 있고 업데이트된 개체를 Java 응용 프로그램이 사용할 수 있습니다. 따라서 응용 프로그램의 네이티브 언어 쪽과 Java 쪽 모두 Java 개체를 작성, 업데이트, 및 접근할 수 있고 둘 사이에 이들 개체를 공유할 수 있습니다.

Example 1의 취약점은 네이티브 메서드 구현의 소스 코드 감사를 통해 쉽게 발견할 수 있습니다. 소스 코드 감사는 C 소스 코드의 가용성 및 프로젝트 구축 방식에 따라 불가능할 수도 있지만 대부분의 경우 이 방법으로 충분합니다. 하지만 Java와 네이티브 메서드 간에 개체를 공유하게 되면 잠재적인 위험이 Java의 부적절한 데이터 처리가 네이티브 코드의 취약점으로 이어지거나 네이티브 코드의 안전하지 못한 작업으로 Java의 데이터 구조가 손상되는 훨씬 심각한 경우로 확대됩니다.

Java 응용 프로그램을 통해 접근되는 네이티브 코드의 취약점은 일반적으로 네이티브 언어로 작성된 응용 프로그램의 취약점 익스플로이트와 같은 방식으로 익스플로이트됩니다. 이 공격의 유일한 난관이라면 공격자가 Java 응용 프로그램이 네이티브 코드를 사용하여 특정 작업을 수행한다는 것을 식별하는 것입니다. 이는 다양한 방법으로 수행할 수 있는데, 예를 들면, 네이티브 코드에서 자주 구현되는 특정 동작을 식별하거나 Java 응용 프로그램에서 JNI 사용을 노출하는 system information leak을 익스플로이트하는 것이 있습니다[2].