¿La interfaz Java nativa de Java / Dalvik JNI hace que Android sea más propenso a los ataques?

3

Java tiene una función llamada Interfaz nativa de Java (JNI) , que permite llamar nativo Función de código de máquina desde dentro del código de bytes de Java. Esta función permite ejecutar efectivamente el código nativo de la máquina desde una biblioteca nativa compartida, que, en el caso de las aplicaciones apk de Android, el desarrollador de la aplicación proporciona dentro del paquete apk.

Mi duda es si este JNI debería ser un problema de seguridad . Es decir. Ese código fuera de la máquina virtual Dalvik, el código nativo directo podría suponer un mayor riesgo de ataque al sistema, ya que es el código de bytes de Java a través de Dalvik.

¿Es el código nativo una mayor preocupación de seguridad que el código en una máquina virtual?

Algunos antecedentes

JNI no es la única forma de ejecutar código nativo, aunque sea conveniente, porque no es necesario hacer muchas copias / incrustaciones de un binario para ejecutarse (es decir, de los activos de APKS a una ubicación ejecutable). posible:

 Runtime.getRuntime().exec("/data/data/my.package/my.code.bin").

Ahora soy consciente de que, en última instancia, no se pierde nada, solo porque se ejecuta el código nativo, por ejemplo. El modelo de seguridad de muchas cajas de escritorio también funciona con aplicaciones nativas en ejecución. De hecho, al menos uno tiene suerte de que Android coloque las aplicaciones en su propio ID de usuario, por lo que se podría decir de primera mano, que incluso de forma nativa es más seguro en Android, que ejecutar Firefox y chromium con el mismo usuario me@mybox en algunas cajas de escritorio. .

El punto curial, que también motiva la pregunta si constituye un problema de seguridad, es que el código nativo me parece mucho más flexible para atacar el sistema a través de llamadas al sistema y sobrecargas de búfer, etc., que un posible ataque desde dentro de la apk / codebase Java de aplicaciones. Después de todo, incluso para cosas legítimas, Dalvik / Java se interpone y se deshabilita debido a su objetivo de portabilidad.

Suponiendo que hay un riesgo asociado con JNI y la llamada del ejecutivo, me estoy equivocando o Android no tiene una configuración de permiso para eso. Así que en respuesta a la evaluación de la pregunta, debería haber "upvotes extra" para confirmar o refutar que Android no tiene una configuración de permisos según la aplicación para JNI. Mi aplicación poc al menos se instala con el mensaje:

  

¿Quieres instalar esta aplicación? No requiere ninguna   acceso especial?

que parece indicarme que no requeriría ningún permiso en absoluto. Sin embargo, sé que puede ejecutar código nativo y código nativo JNI.

    
pregunta humanityANDpeace 10.03.2016 - 14:44
fuente

3 respuestas

1
  

si este JNI debería ser un problema de seguridad?

Lo que es o no es una "preocupación" es una declaración de opinión, para la cual la familia de sitios de Overflow no está bien adaptada.

  

¿Es el código nativo una mayor preocupación de seguridad que el código en una máquina virtual?

Lo describiría como diferente . Algunos ataques serían más fáciles desde el código nativo, como los que describe en su pregunta. Otros ataques serían más difíciles, ya que el código nativo carece de API para obtener muchas cosas en Android a las que se puede acceder más fácilmente desde el código Java. Si uno es "más grande" es, nuevamente, una declaración de opinión.

  

confirmando o refutando que Android no tiene una configuración de permisos según la aplicación para JNI

Correcto. No se pregunta al usuario si la aplicación contiene o no código nativo de alguna forma. Eso no es realmente para lo que es el sistema de permisos. Más allá de eso, no me queda claro lo que le diría al usuario sobre JNI en un mensaje de permiso ("Esta aplicación hace un mumbo-jumbo técnico diferente al de las aplicaciones de Android comunes. ¿Permitir? ¿Denegar?").

    
respondido por el CommonsWare 10.03.2016 - 15:16
fuente
1

Cualquier aplicación ejecuta código nativo al final. Esto es cierto para Android con su JVM (Dalvik o ART), y para iOS, y para Windows, e incluso para SmallTalk. El código nativo tiene un "vector de ataque" ligeramente diferente al código administrado: algunos tipos de vulnerabilidades, por ejemplo, desbordamiento de búfer, pertenecen a nativo, no a Java. Y las hazañas maliciosas pueden encontrar y abusar de tales vulnerabilidades.

Pero en Android, el código nativo, y especialmente lo que entendemos por código JNI (las piezas de software de terceros o de terceros, escritas en C ++ o en algún otro lenguaje no administrado), este código se ejecuta en la misma aplicación Sandbox, sujeto a las mismas restricciones de seguridad que el código Java. En Andorid, su código nativo no puede escribir en la tarjeta SD sin un permiso explícito de manifiesto: no porque la API esté marcada como "prohibida" (alusión a la seguridad de AppStore al verificar qué API utiliza la aplicación), sino porque el sistema prohíbe proactivamente dicho acceso, asignando los permisos apropiados para cada proceso.

Deberíamos preocuparnos mucho más por el código del sistema que se ejecuta en procesos "elevados", donde un exploit puede adquirir acceso a la raíz y controlar todo el dispositivo (alusión a la vulnerabilidad reciente de stagefright, que secuestra el servicio de medios).

Estoy de acuerdo con la respuesta anterior de que no sería apropiado hacer preguntas a los usuarios finales promedio que no tienen sentido para ellos, especialmente cuando estas son preguntas relacionadas con la seguridad.

Estoy de acuerdo con usted en que escribir un código no administrado es difícil, y todo tipo de errores humanos pueden hacer que el código JNI sea menos sólido que el código Java. Bueno, esta debe ser principalmente la preocupación del desarrollador. El impacto negativo de tales errores en el prestigio del desarrollador es mucho mayor que el posible daño de seguridad al usuario final.

Google ha repetido el resultado final: C ++ no es Mt.Everest. No vayas a C ++ solo porque está ahí. Evalúe los riesgos y las ganancias con cuidado, y probablemente encontrará que Java será mejor para usted.

    
respondido por el Alex Cohn 14.03.2016 - 18:12
fuente
1

Sí, absolutamente.
De hecho, esta respuesta es un tanto trivial, ya que el nativo obviamente sería vulnerable a clases adicionales de ataques, como el desbordamiento de búfer, tal como lo señala en su pregunta.

Hay un CWE (111) muy específico que se aplica aquí :

  

Cuando una aplicación Java utiliza la Interfaz Nativa de Java (JNI) para llamar a un código escrito en otro lenguaje de programación, puede exponer la aplicación a puntos débiles en ese código, incluso si esos puntos débiles no pueden ocurrir en Java.

Ahora, lo interesante aquí es en realidad la caja de arena de Android.
Si bien las vulnerabilidades mencionadas son de hecho relevantes aquí, y hacen que el código nativo tenga un mayor riesgo, eso no necesariamente permite que una biblioteca se separe y escape de la caja de arena de privilegios. Como usted dice, las aplicaciones de Android se ejecutan con su propio UID y privilegios limitados, por proceso.
De hecho, me parece muy poco probable, aunque no imposible, si lo encuentra, sería una buena revelación, y espero que se solucione en poco tiempo.

    
respondido por el AviD 12.12.2016 - 09:24
fuente

Lea otras preguntas en las etiquetas