Unsafe JNI

O uso indevido da JNI (Java Native Interface) pode tornar aplicativos Java vulneráveis a falhas de segurança em outras linguagens.

Erros de JNI não segura ocorrem quando um aplicativo Java usa a JNI para chamar um código escrito em outra linguagem de programação.
Exemplo 1: O seguinte código Java define uma classe denominada Echo. A classe declara um método nativo que usa C para ecoar comandos inseridos no console de volta para o usuário.

    class Echo {
	public native void runEcho();

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

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

O código C a seguir define o método nativo implementado na classe Echo:

#include <jni.h>
#include "Echo.h" //a classe java do Example 1 compilada com javah
#include <stdio.h>

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

Como o exemplo é implementado em Java, pode parecer que ele é imune a problemas de memória, como vulnerabilidades de buffer overflow. Embora o Java faça um bom trabalho de garantir a segurança de operações de memória, essa proteção não se estende a vulnerabilidades que ocorrem no código-fonte escrito em outras linguagens que são acessadas usando a Java Native Interface. Apesar das proteções de memória oferecidas em Java, o código C nesse exemplo é vulnerável a um buffer overflow por utilizar gets(), que não realiza nenhuma verificação de limites em sua entrada.

O Sun Java(TM) Tutorial fornece a seguinte descrição da JNI [1]:

A estrutura JNI permite que seu método nativo use objetos Java da mesma forma que o código Java usa esses objetos. Um método nativo pode criar objetos Java, incluindo arrays e strings, e depois inspecionar e usar esses objetos para realizar suas tarefas. Um método nativo também pode inspecionar e usar objetos criados pelo código do aplicativo Java. Um método nativo pode até mesmo atualizar objetos Java que ele criou ou que foram transmitidos para ele, e esses objetos atualizados estão disponíveis para o aplicativo Java. Portanto, tanto o lado da linguagem nativa quanto o lado do Java de um aplicativo podem criar, atualizar e acessar objetos Java e depois compartilhar esses objetos entre eles.

A vulnerabilidade no Example 1 pode ser facilmente detectada por meio de uma auditoria de código-fonte da implementação do método nativo. Isso pode não ser prático ou possível, dependendo da disponibilidade do código-fonte C e de como o projeto está estruturado, mas, em muitos casos, pode ser suficiente. No entanto, a capacidade de compartilhar objetos entre métodos Java e nativos expande o possível risco de casos muito mais traiçoeiros nos quais a manipulação imprópria de dados pode fazer com que vulnerabilidades inesperadas ou operações não seguras no código nativo corrompam estruturas de dados em Java.

Vulnerabilidades no código nativo acessado por meio de um aplicativo Java são geralmente exploradas da mesma maneira do que em aplicativos escritos na linguagem nativa. O único desafio a um ataque desse tipo é que o atacante deve identificar que o aplicativo Java usa um código nativo para realizar determinadas operações. Isso pode ser feito de uma variedade de maneiras, entre elas identificando comportamentos específicos que muitas vezes são implementados com código nativo ou explorando um vazamento de informações do sistema no aplicativo Java que expõe seu uso de JNI [2].