3

Java has a feature named Java Native Interface (JNI), which allows to call native machine code function from inside the Java's bytecode. This feature allows effectively running machine native code from a native shared library, which -in the case of Android apk apps- the app developer provides inside the apk package.

My doubt is if this JNI should this be a security concern? I.e. that code outside of Dalvik virtual machine, direct native code could be imho a higher risk to attack the system, as it the java bytecode through Dalvik?

Is native code a bigger security concern than code in a virtual machine?

Some Background

JNI is not the only way to run native code, albeit a conveniend one because one does not have to do lots of copying/embedding of a binary to run (i.e. from the apks assets to a executable location) Anyway also this is possible:

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

Now I am aware that, nothing is yet ultimately lost, only because native code is executed, e.g. the security model of many desktop boxes also works with native applications running. Indeed one is at least lucky that Android stuffs apps into their own user id UID, so one might at first hand say, that even natively one is safer on Android, than running firefox and chromium with the same me@mybox user on some desktop boxes.

The curcial point, which also motivates the question if it constitutes a security concern, is that native code appear to me much more flexible to attack the system via systemcalls and buffer overruns etc, than possible for an attack occuring from within the apk/apps Java codebase. After all even for legitimate stuff Dalvik/Java gets much in the way and is disabled because of its portability goal.

Assuming there is a risk associated with JNI and the exec call, am I mistaking or does Android lack a permission setting for that. So in attition to evaluation the question, there should be "extra upvotes" for confirming or refuting that Android does not have as-per-app permission settings for JNI. My poc app at least installs with the message:

Do you want to install this application? It does not require any special access?

which seems to indicate to me that it would not require any permission at all. Yet I know it can run native code and JNI native code.

1

Yes, absolutely.
In fact this answer is kinda trivial, in that native would obviously be vulnerable to additional classes of attack, such as buffer overflow - just as you note in your question.

There is a very specific CWE (111) that applies here:

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.

Now, the interesting thing here is actually the Android sandbox.
While the vulnerabilities mentioned are in fact relevant here, and do make the native code higher risk, that does not necessarily enable a library to break out and escape the privilege sandbox. As you say, Android apps run with their own UID and limited privileges, per process.
In fact I find this highly unlikely, though not impossible - if you do find it, that would be a nice disclosure, and hopefully it would be fixed in short order.

1

Any app runs native code in the end. This is true for Android with its JVM (both Dalvik or ART), and for iOS, and for Windows, and even for SmallTalk. The native code does have slightly different "vector of attack" than the managed code: some kinds of vulnerabilities, e.g. buffer overflow, belong to native, not Java. And malicious exploits can find and abuse such vulnerabilities.

But on Android, the native code, and especially what we usually mean by JNI code - the pieces of home-grown or 3rd party software, written in C++ or some other non-managed language - this code runs in the same app sandbox, subject to the same security restrictions as the Java code. On Andorid, your native code cannot write to SD card without explicit manifest permission: not because the API is marked as "forbidden" (allusion to AppStore security by checking which APIs the app use), but because the system proactively prohibits such access, assigning the appropriate permissions to each process.

We should worry much more about the system code that runs in "elevated" processes, where an exploit can acquire root access and pown the whole device (allusion to the recent stagefright vulnerability, which hijacks the media service).

I agree with the previous answer that there it would not be appropriate to ask an average end-users questions that make no sense to them, especially when these are security-related questions.

I agree with you that writing non-managed code is hard, and all kinds of human mistakes can render JNI code less robust than the Java code. Well, this should primarily be the developer's concern. The negative impact of such errors on the developer's prestige is much higher than potential security damage to the end-user.

The bottom line has been repeated by Google again and again: C++ isn't Mt.Everest. Don't go C++ just because it's there. Weight the risks and gains carefully, and probably you will find that you will be better served by pure Java.

  • sure there can be coding mistakes in the JNI/exec-native code, being unintented security risks. My question anyway rather wanted to look at the case: someone wants to use a apk package as trojan horse actually trying to break out of the uid-based sandbox. For the latter scenario I was thinking that coding natively, accessing the systemcalls might offer better ways for priveledge escalation, than the managed Java. I do of course not want to write such software, I simply figured it was possible, and also I prefere not coding in Java whenever possible – humanityANDpeace Mar 15 '16 at 8:47
  • With this slightly different formulation, your question can be answered this way: no, presence of native libraries per se does not make an app more suspected to be a trojan. But if you see native library in an app that has no apparent reason to have one (e.g. a child memory game), you can suspect that something does not smell right. If you personally don't like Java, you can use Scala or other language that will produce byte code to run on the same JVM. – Alex Cohn Mar 15 '16 at 10:23
1

if this JNI should this be a security concern?

What is or is not a "concern" is a statement of opinion, for which the Stack Overflow family of sites is not well-suited.

Is native code a bigger security concern than code in a virtual machine?

I would describe it as different. Some attacks would be easier from native code, such as the ones that you outline in your question. Other attacks would be more difficult, as native code lacks APIs to get at lots of things in Android that can be accessed more easily from Java code. Whether one is "bigger" is, again, a statement of opinion.

confirming or refuting that Android does not have as-per-app permission settings for JNI

Correct. The user is not prompted as to whether or not the app contains native code of any form. That's not really what the permission system is for. Beyond that, it is unclear to me what you would tell the user about JNI in a permission prompt ("This app does different technical mumbo-jumbo than do ordinary Android apps. Allow? Deny?").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.