Use of native code

OWASP category: MASVS-CODE: Code Quality

Overview

Android applications can take advantage of native code written in languages like C and C++ for specific functionalities. However, when an application utilizes the Java Native Interface (JNI) to interact with this native code, it potentially exposes itself to vulnerabilities like buffer overflows and other issues that may be present in the native code implementation.

Impact

Despite very positive impacts such as performance optimization and obfuscation, utilizing native code in Android applications can have negative security impacts. Native code languages like C/C++ lack the memory safety features of Java/Kotlin, making them susceptible to vulnerabilities like buffer overflows, use-after-free errors, and other memory corruption issues – leading to crashes or arbitrary code execution. Additionally, if a vulnerability exists in the native code component, it can potentially compromise the entire application, even if the rest is written securely in Java.

Mitigations

Development and coding guidance

  • Secure Coding Guidelines: For C/C++ projects, adhere to established secure coding standards (e.g., CERT, OWASP) to mitigate vulnerabilities like buffer overflows, integer overflows, and format string attacks. Prioritize libraries like Abseil known for quality and security. Whenever possible, consider adopting memory-safe languages like Rust, which offer performance comparable to C/C++.
  • Input Validation: Rigorously validate all input data received from external sources, including user input, network data, and files, to prevent injection attacks and other vulnerabilities.

Harden the compilation options

Native libraries utilizing the ELF format can be hardened against a range of vulnerabilities by activating protective mechanisms like stack protection (Canary), relocation read-only (RELRO), data execution prevention (NX), and position-independent executables (PIE). Conveniently, the Android NDK compilation options already enable all these protections by default.

To verify the implementation of these security mechanisms within a binary, you can employ tools like hardening-check or pwntools.

Bash

$ pwn checksec --file path/to/libnativecode.so
    Arch:     aarch64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

Verify third-party libraries are not vulnerable

When choosing third-party libraries, prioritize using those with a solid reputation in the development community. Resources like the Google Play SDK Index can help you identify well-regarded and trustworthy libraries. Ensure you keep the libraries updated to the latest versions and proactively search for any known vulnerabilities related to them using resources like the databases from Exploit-DB. A web search using keywords like [library_name] vulnerability or [library_name] CVE can reveal critical security information.

Resources