Security flag fstack-protector

[DavidBarreraChindo]

Expected Results

better security the app

Actual Results

stack canaries can greatly increase the difficulty of exploiting a stack buffer overflow because it forces the attacker to gain control of the instruction pointer by some non-traditional means such as corrupting other important variables on the stack. Built with option -fstack-protector"

ib/x86_64/libtool-checker.so lib/x86_64/librealm-jni.so lib/x86/libcrashlytics-envelope.so lib/x86/librealm-jni.so lib/armeabi/librealm-jni.so lib/armeabi-v7a/librealm-jni.so lib/arm64-v8a/librealm-jni.so lib/mips/librealm- jni.so

Steps & Code to Reproduce

I developed an android application and a security team realized a security testing and sent me a vulnerability that doesn't have "-fstack-protector" option the Realm library

Version of Realm and tooling

Realm version(s): io.realm:realm-gradle-plugin:1.1.1

my question is if a reason why doesn't it have it? or what can i do? or Is there a risk?

i hope that you can help me

[cmelchior]

As a general purpose project, we have to continuously evaluate the trade-off between performance and safety. In this case you are talking about a program running on a mobile device, so if an attacker has the level of access to attack an app with Realm, they already have access to modify/see the Realm file using normal API's. None of the Java API's would allow this kind of attack vector.

That said, we haven't really tried to enable this setting (which according to @kneth should be fstack-protector-strong to work on ARM) and we would need to test what difference it does to our binary size as well as the performance before being able to commit to anything.

Both Realm Java and Realm Core is open source though, so if you want to, you add this flag to both places in order to build your own version of Realm

[kneth]

When we are able to upgrade to a recent NDK version, we might also experimenting with FORTIFY: https://android-developers.googleblog.com/2017/04/fortify-in-android.html

[dmarjanovic]

Can you please rethink about supporting use of fstack-protector-strong in Realm since it's not so good practice of ignoring known security vulnerabilities (reported by pentests as severity:high) especially for security critical applications that use Realm? In our scenario building Realm from source is not realistic due to increasing complexity of already complex projects. /cc cmelchior

@kneth, FORTIFY only points to existing buffer overflow issues but does not mitigate security issue, or I see it wrong.

[cmelchior]

As pointed out in https://github.com/realm/realm-java/issues/4553#issuecomment-297126814, even if there is an attack vector in the C++ code itself, there is no way to exploit that as all access goes through well-defined boundaries in Java. So for all practical purposes, this is a false positive in terms of using Realm Java.

That doesn't mean we don't want to look into ways to remove such warnings anyway as it annoying to see such warnings when running tools of that kind, but it isn't a very high priority for us, so I cannot give you any timeframe when we might be able to look at this.

[atanascu]

@cmelchior ca you better explain this ?

there is no way to exploit that as all access goes through well-defined boundaries in Java

All access to what? The realm c++ code?

[cmelchior]

Yes. I mean you can, of course, add native code of your own that work around the Realm Java API. But if you are in a position to do that, then you already have privileges far above the kind of attacks stack canaries will protect against.

[yannleretaille]

We just noticed the same issue (automated testing tools flagging this library as insecure). It would be nice if you would consider adding the flags to the build parameters in the future.

[pjq]

Customer report the same issue, so any progress.

[Zhuinden]

The progress is that "if you need this then you can compile Realm yourself", if I read the past correctly

[cmelchior]

NDK18 and above has this flag enabled by default, so we will probably do the same once we upgrade to it.

But as noted in https://github.com/realm/realm-java/issues/4553#issuecomment-297126814, using this flag has no practical security implications when using Realm from the Java side. It would only have an effect if you directly interacted with the Realm API's from the C++ side, and if you where able to do that you would already have breached the Android Sandbox and would be able to either copy or manipulate Realm files in other ways.

[cmelchior]

With Realm Java 7.0 and above, we are using NDK 21 which has this flag enabled by default. It does add something like 50 kB to the final size of the .so file, but that seems low enough that we should just keep it for now. Closing