Unsafe JNI

El uso inadecuado de la interfaz nativa de Java (JNI, por sus siglas en inglés) puede provocar que las aplicaciones de Java sean vulnerables a los errores de seguridad de otros lenguajes.

Los errores de JNI poco segura se producen cuando una aplicación de Java usa JNI para llamar a código escrito en otro lenguaje de programación.
Ejemplo 1: El siguiente código de Java define una clase denominada Echo. La clase declara un método nativo que utiliza C para devolver comandos introducidos en la consola al usuario.

    class Echo {
	public native void runEcho();

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

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

El siguiente código C define el método nativo implementado en la clase Echo:

#include <jni.h>
#include "Echo.h" //the java class from Example 1 compiled with javah
#include <stdio.h>

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

Como el ejemplo se ha implementado en Java, es posible que parezca que es inmune a los problemas de memoria como, por ejemplo, las vulnerabilidades de buffer overflow. Aunque Java es eficaz a la hora de proteger las operaciones de memoria, esta protección se amplía a las vulnerabilidades que se producen en el código fuente escrito en otros lenguajes a los que se accede mediante la interfaz nativa de Java. A pesar de las protecciones de memoria ofrecidas en Java, el código C de este ejemplo es vulnerable a un buffer overflow debido a que utiliza gets(), que no realiza ninguna comprobación de límites en su entrada.

El tutorial de Sun Java(TM) ofrece la siguiente descripción de JNI [1]:

La estructura JNI permite al método nativo utilizar objetos de Java del mismo modo que el código de Java. Un método nativo puede crear objetos de Java, incluidas matrices y cadenas, y, a continuación, inspeccionar y usar estos objetos para realizar sus tareas. Un método nativo también puede inspeccionar y utilizar objetos creados por el código de aplicación de Java. Un método nativo puede incluso actualizar objetos de Java que este haya creado o que se hayan transferido al mismo; estos objetos actualizados están disponibles en la aplicación de Java. Por consiguiente, tanto la parte de lenguaje nativo como de Java de una aplicación pueden crear y actualizar objetos de Java, además de acceder a ellos, y, continuación, compartir estos objetos entre ellas.

La vulnerabilidad presente en el Example 1 podría detectarse fácilmente a través de una auditoría de código fuente de la implementación del método nativo. Es posible que esto no resulte factible o práctico en función de la disponibilidad del código fuente de C y el modo en que se ha creado el proyecto, aunque en la mayoría de los casos será suficiente. Sin embargo, la capacidad para compartir objetos entre los métodos de Java y nativos eleva el riesgo potencial a casos mucho más insidiosos en los que una administración inadecuada de los datos en Java puede provocar vulnerabilidades inesperadas en el código nativo u operaciones poco seguras en las estructuras de datos dañados del código nativo en Java.

Las vulnerabilidades del código nativo al que se accede mediante una aplicación de Java se suelen explotar del mismo modo que en las aplicaciones escritas en el lenguaje nativo. El único desafío frente a un ataque de este tipo es que el usuario malintencionado identifique la aplicación de Java que utiliza código nativo para realizar determinadas operaciones. Esto se puede lograr de diversas maneras, incluida la identificación de comportamientos específicos que a menudo se implementan con código nativo o mediante la explotación de una pérdida de información del sistema en la aplicación de Java que muestra su uso de JNI [2].